DeepSQL on the CLI: the brain for your database, where you already work

TL;DR

• DeepSQL now ships as a CLI. Install it, point it at your database, and you have a DBA + BI + Schema Guardian agent living in your terminal.
• It is not another psql wrapper or a text-to-SQL toy. It reads your schema, your workload, your plans, your recent migrations, and answers in plain English with real SQL underneath.
• Three intents from day one: DBA ("is this query using the right index?"), BI ("top 10 customers by spend"), Guardian ("what schema changed recently?"). All from one prompt.

Why a CLI, and why now

Every database tool I have ever loved lived in a terminal. psql, mysql, sqlplus, rman. Every database tool I have ever quietly hated lived in a browser tab that timed out at the worst possible moment.

When we started building DeepSQL, the easy path was a hosted web console. We did the opposite. The CLI is the product. The web is a viewer.

Here is why. The people who actually carry a database in production — DBAs, data engineers, platform engineers, senior backend folks — already live in tmux. They have aliases. They have a prod jump host. They have a read-replica connection string they will not paste into a SaaS form. Putting an agent anywhere except the terminal is asking them to change how they work, on the day they are already debugging a Sev-2.

So we put the brain in the terminal.

venkat@Venkats-MacBook-Air mcp % deepsql

I am your DBA and Data agent. DeepSQL is the brain for your database

Try these prompts
  DBA prompt       "is this query using the right index?"
  BI prompt        "top 10 customers by spend"
  Guardian prompt  "what schema changed recently?"

Ask a question · exit to quit · deepsql --help for CLI commands
v0.23.0 · latest

deepsql › who are top 3 paying customers?

That is the entire onboarding. No dashboard, no workspace, no "invite your team" modal. Type deepsql, ask a question, get an answer that is correct against your live schema.

What's actually under the hood

A text-to-SQL demo is a 200-line script. A DBA agent is not. The CLI ships with three things that took us months to get right:

1. A schema brain, not a schema dump. On first connect, DeepSQL reads information_schema, pg_stats, pg_indexes, pg_stat_user_tables, pg_stat_statements, and the recent DDL history. It does not stuff this into a prompt. It builds a compact, queryable model of your database — column cardinalities, FK graph, partition layout, index coverage, hot tables by IO. The LLM never sees the raw catalog. It sees the brain.

2. A plan-aware loop. When you ask "is this query using the right index?", the agent does not guess from the SQL string. It runs EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) against the read-replica, parses the plan tree, looks at the predicates, checks pg_stats for selectivity, and only then tells you what is wrong. If it proposes a rewrite, it re-runs EXPLAIN on the rewrite and shows you the cost delta before suggesting a PR.

deepsql › is this query using the right index?
> SELECT * FROM orders WHERE DATE(created_at) = '2026-06-01';

Plan:    Seq Scan on orders  (cost=0.00..184219.00 rows=4,210,000)
Issue:   DATE(created_at) wraps an indexed column → index ix_orders_created_at not used.
Rewrite: WHERE created_at >= '2026-06-01' AND created_at < '2026-06-02'
Replan:  Index Scan using ix_orders_created_at  (cost=0.43..812.40 rows=12)
Delta:   ~225x fewer rows, ~80% less buffer reads. Ship it?

3. Three personalities, one context. DBA, BI, and Guardian are not three products. They are three intents the same brain answers. The BI prompt walks the FK graph and writes correct joins. The DBA prompt walks pg_stat_statements and ranks regressions. The Guardian prompt diffs DDL history and flags the irreversible ones — a wrong PK type, a DROP CONSTRAINT NOT VALID, a partition key that nobody can ever change back without weeks of dual-write.

That last one matters more than the other two combined. A bad commit, you revert. A bad LLM token bill, you cap. A bad schema decision on a 5TB table, you live with for the life of the company. Guardian is the seat belt the database layer has never had.

What it replaces

Be specific or it sounds like marketing. From real users in the first two weeks:

• The "ping the DBA on Slack at 2am" workflow. Engineers run deepsql against staging, get an EXPLAIN-grounded answer, and ship without paging anyone.
• The "spin up a Metabase question for the CFO" workflow. PMs run deepsql › top 10 customers by spend last quarter. SQL is correct because the brain knows which customers table is the real one and which customers_archive is the 2019 dump nobody dropped.
• The "diff two migration branches and pray" workflow. Guardian shows you the column type change, flags that the column is referenced by 14 FKs, and tells you the rollback cost in advance.

None of these are net-new dashboards. They are workflows that already existed, executed badly, by humans with no time. The agent does them in one prompt.

A note from the Oracle days

When I owned the Zonemaps module at Oracle, the lesson that stuck was this: the optimizer is downstream of everything. Downstream of the schema, downstream of the stats, downstream of the data distribution. A perfect query engine cannot save a wrong partition key. A perfect index advisor cannot save a jsonb column being SELECT *-ed a million times an hour.

Tools that only see SQL miss the actual problem. DeepSQL was built from day one to see the shape of the data underneath the SQL — which is exactly what a senior DBA does in their head before they answer your question. The CLI is just the surface. The brain is the product.

Install

DeepSQL setup (this also sets up mcp/cli on the machine where deepsql is installed)

curl -fsSL https://install.deepsql.ai/install.sh | bash

For connecting to DeepSQL on a remotely hosted environment, here is the mcp/cli client setup:

npm install -g @deepsql/mcp@latest

Then deepsql init against any Postgres, Aurora Postgres, or MySQL connection string. Read-only by default. Writes require a flag and a confirmation. Schema changes require Guardian's sign-off.

v0.23.0 is live. MySQL parity, MCP server mode, and a deepsql ci hook for blocking risky migrations in PRs are next.

What DeepSQL does about this

The CLI is how you talk to DeepSQL. Underneath, it is doing the work that organizations currently pay three different teams to do badly — DBA triage, BI analyst translation, and schema review. It grounds every answer in the live database (EXPLAIN plans, pg_stat_statements, DDL diff), refuses to rubber-stamp the irreversible changes that a coding agent would happily merge, and meets the people who own the database where they already work — in a terminal, on a jump host, at 2am. For any team where the database is the system of record, this is the deployment that finally makes prevention cheaper than cure.