How to chat with your PostgreSQL database in plain English

Most teams that use PostgreSQL in production have one analyst who writes 80% of the SQL and a backlog of "quick questions" from non-engineers waiting on them. The fix in 2026 is not "teach everyone SQL." The fix is to put a chat interface in front of the database that knows your schema.

This guide shows what actually works.

Why naive prompting against Postgres fails

Pasting "what were our top 10 customers by revenue last quarter?" into ChatGPT and pasting the output back into psql gets you about 30% accuracy. The model doesn't know your column names, your join keys, your timezone conventions, or which of your three "users" tables is the live one.

The accuracy jump comes from giving the model schema context before the question. Specifically:

• The full DDL of relevant tables (≤ 30 tables; otherwise pre-filter via embedding similarity)
• Sample row data (5–10 rows per table)
• A short natural-language description per table when names are ambiguous (txn → "settled credit-card transactions, one row per capture event")
• Foreign-key relationships, even when not explicitly declared

Once the model has all of that, plain-English-to-SQL accuracy on a typical OLTP schema runs around 88–94% on first attempt.

The architecture that works

There are three production-ready patterns. Pick by how much you want to operate yourself.

1. Self-hosted: schema introspection + frontier LLM + verification loop

This is the Vanna AI pattern. The loop:

1. On connect: introspect schema. Pull information_schema.tables, information_schema.columns, primary keys, foreign keys, and 5 sample rows per table.
2. On user prompt: embed the prompt + each table's schema; pick the top-K most relevant tables (K=10 is a good default).
3. Send to the LLM: {schema, samples, prompt, last 3 messages of conversation}.
4. Get back SQL. Don't run it blindly. Run EXPLAIN first to confirm it parses.
5. Run with SET statement_timeout = 30000 and SET LOCK_TIMEOUT = 5000 so a runaway query can't lock the table.
6. Show the user the generated SQL alongside the result so they learn the schema.

Latency: 2–6 seconds end-to-end on a current cost-efficient frontier LLM. Cost in API fees: roughly $0.0008–$0.004 per question depending on schema size.

2. Fully on-prem with a smaller open-source model

If your data must never leave your infrastructure, you can keep everything in-house. Store schema embeddings in your own vector store (pgvector works fine inside Postgres) and run a small open-source LLM for SQL generation. Accuracy drops to roughly 75% on the first attempt — survivable for internal tooling, painful for customer-facing.

3. Buy: a managed product that does all of the above

This is the right move for almost everyone. Building the loop yourself looks easy on day one and gets ugly the moment you start handling: timezone columns that aren't TIMESTAMPTZ, JSONB columns that need ->> access, multi-tenant row-level security, RBAC, audit logs, query history, conversation memory, and the inevitable "the AI hallucinated a column name" debugging.

A managed multi-source assistant handles the operational work; you connect Postgres and start asking questions. PostgreSQL connection setup takes about 30 seconds with read-only credentials.

A real example

Here's a sales pipeline question on a real Postgres schema:

> Top 10 closed-won deals in the last 90 days, grouped by sales rep

The AI generates:

SELECT
  u.full_name AS sales_rep,
  COUNT(*) AS deals_closed,
  SUM(d.amount_cents) / 100.0 AS total_revenue
FROM deals d
JOIN users u ON u.id = d.owner_id
WHERE d.stage = 'closed-won'
  AND d.closed_at >= NOW() - INTERVAL '90 days'
GROUP BY u.full_name
ORDER BY total_revenue DESC
LIMIT 10;

Notice it correctly used amount_cents / 100.0 because the schema sample showed integer cents, picked the right join column, and constrained the date range with an interval. None of that came from the prompt — it came from the schema context.

Safety: what to lock down before you ship this to non-engineers

The risk is not "the AI generates bad SQL" — it's "the AI generates a query that locks a production table for 8 minutes during a sale." A real shipping checklist:

1. Use a read-only Postgres role. Granted SELECT on the views/tables you want exposed; nothing else.
2. Set query timeouts at the role level: ALTER ROLE ai_reader SET statement_timeout = '30s';
3. Set a row limit in the AI tool config (most managed products default to 1,000 rows).
4. Block known-dangerous patterns before execution: pg_sleep, COPY ... FROM PROGRAM, CREATE, DROP, ALTER. Even though your role can't do these, blocking them in app code returns a clearer error.
5. Log every generated query — not the prompt, the SQL — for a 90-day audit window.
6. Show the SQL to the user every time. Builds trust, lets them catch hallucinations, doubles as schema-learning material.

Trade-offs and when this is wrong

This approach is wrong when:

• Sub-100ms latency matters. The chat round-trip is 2–6 seconds. Use it for analysis, not for serving customer-facing dashboards from a UI button click.
• Your schema is genuinely chaotic. Tables named a1, a2, temp_old_x. Either clean up the schema or accept lower accuracy.
• You have ≥ 500 tables. Embedding-based table selection works up to a few hundred; beyond that the relevance retrieval gets noisy. Multi-source projects with namespacing per dataset solve this.
• Compliance requires SQL written by a human. Some healthcare and finance regulations need a human-in-the-loop for any query touching regulated data.

Conclusion

In 2026, "chat with your Postgres database" is a solved problem when you give the model schema context, run with a read-only role, enforce query timeouts, and show the generated SQL to the user. Build it yourself if you want to learn; buy it if you want it shipped this week.

If you're solving this exact problem, iDBQuery is built for it — connect a Postgres database in 30 seconds and ask questions. Free tier covers 1M tokens / month — no credit card.

FAQ

How accurate is plain-English-to-SQL on Postgres in 2026? With proper schema context and a top-tier LLM, expect 88–94% first-attempt accuracy on typical OLTP schemas. With smaller models or no schema context, accuracy drops to 30–60%.

Does it work on PostGIS spatial queries? Yes — modern tools recognize PostGIS extensions and generate ST_* functions. Geospatial chat works for boundary queries, distance filters, and choropleth aggregations out of the box.

What about JSONB columns? The model handles -> and ->> access correctly when sample rows include JSONB content. Nested deeply-typed JSON sometimes needs a hint in the prompt ("prefs is JSONB with keys: theme, locale, notifications").

Will it work with a read replica? Yes — and you should. Connect with a read-only role pointing at your follower replica. Production primary stays untouched.

How much does it cost per query? At market API rates for a current cost-efficient frontier LLM, expect roughly $0.0008–$0.004 per question depending on how much schema context is sent. iDBQuery's free tier covers this at $0 to the user — 1M tokens/month is enough for a typical individual or small team.

Do users need to know SQL? No. The whole point is they don't. But power users like seeing the generated SQL — it doubles as documentation.