Ask your database anything — read-only, in your browser.

A tool that lets you explore tables, rows and relationships in any database from the browser — no desktop SQL client per engine. DBShifts Data Console connects to MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, MariaDB and SQLite, and gives you filtering, search, foreign-key navigation and CSV export in one read-only interface.

The Data Console is read-only by construction — it can never write to your database. Every connection is allowlisted, every action lands in an activity log, and sensitive columns can be masked so browsing never exposes raw PII.

The console scans your tables for emails, phone numbers, credit cards, SSNs and other sensitive data using deterministic pattern detection (with Luhn validation for cards) on sampled rows — so you know exactly where regulated data lives before it moves or gets shared.

Use cross-engine reconciliation: pick any two connected databases and a table, and the console compares row counts plus type-aware row checksums — sampled for speed or exact for certainty — even across different engines. Scheduled monitors re-check continuously and alert on drift.

Yes — share a data source read-only with masked columns, grant unmask rights only where justified, and run an access review that reports who can browse and who can unmask across every source, with a CSV your auditor will accept. For staging, generate masked, FK-intact test-data copies instead of sharing production.

Commit a snapshot of any table and DBShifts hashes it row-by-row — only what actually changed is stored, so history costs almost nothing to keep. Diff any two commits to see exactly which rows were added, removed, or changed, branch to try something in isolation, and merge back with conflicts flagged instead of silently overwritten.

Yes. Ask lets you type a question like “which country sends the most orders?” or “how many customers signed up last month?” and get the answer from your real data. It runs against the same read-only, governed connection as the rest of the console, so masked columns stay masked and every lookup is recorded. You bring your own AI provider key (Anthropic or OpenAI) — DBShifts never supplies or bills for one.

Text-to-SQL tools generate a SQL string and run it, which means the model decides what your database executes — and any masking or column rule that lived in your application is bypassed. DBShifts Ask generates no SQL at all. The model can only call three structured, allowlisted tools (list tables, read rows, aggregate), each validated against your schema before anything touches the database. Grouping by a masked column is refused outright, because grouping enumerates the distinct raw values it was meant to hide.

Only if you turn it on, per data source, and only the rows needed to answer the question you asked. Ask is off by default. Masking is applied before anything is sent, so a redacted column never reaches the model. Each question is written to the audit log with the tables it read, and because it is your own API key, the request goes from your DBShifts instance to your provider account — there is no shared middleman model.

Yes. Ask can join a table to one it references and aggregate across the join — that is what answers 'which customer spent the most' or 'revenue by region' correctly over a whole table rather than one page of rows. Joins follow the foreign keys already in your schema, so the model cannot invent a relationship between unrelated tables, and grouping by a masked column is refused on either side of the join.

DBShifts charges nothing for it — you bring your own Anthropic or OpenAI key, so you pay your provider directly at their rates and nothing passes through us. Every question records the tokens it used, Console Settings shows the running total for the month, and a monthly token cap is set by default (2,000,000) so a mistake cannot become a surprise bill. Set it to 0 to remove the cap.

Yes — connect any database and get read-only browsing, automatic PII discovery, masked-by-default access, granular unmask grants, scheduled access reviews and a full audit trail in one place. It's the operational layer of data governance: knowing exactly what data you have, who can see it, and proving that on demand.