Text-to-SQL tools for Postgres differ on what SQL is allowed to run

Every text-to-SQL tool turns a question into a statement and runs it. The differences that decide production fit are narrower than the category pitch suggests: what the execution path will accept, how much data one answer can return, where the reusable query logic is stored, and how the vendor bills.

Chion generates a new SELECT for every question. That SELECT is anchored on a base query someone on your team saved and reviewed in Studio, then checked in code before it runs: the first layer rejects anything that is not a read-only SELECT, the second runs a forbidden-keyword check over the statement, and execution is wrapped with a statement timeout and a row limit. The result carries the statement that produced it, so the agent evaluation a reviewer runs is on real SQL, not a description of it.

Saving a query for reuse is a human step. A query becomes a base query when a person reviews it in Studio and saves it, and only saved and reviewed SQL is compiled into an exported skill.

Schema hallucination. The model invents column names that look right but do not exist (customer_lifetime_value when the real column is ltv_usd). Runs in dev, fails in prod, takes an hour to debug.

Join drift. The model picks a join key that is correct for one question and wrong for the next (user_id vs account_id vs customer_id) and you only notice when the numbers do not tie out to last quarter’s report.

Aggregation errors. AVG of pre-computed ratios, SUM across snapshot tables, COUNT DISTINCT on a column that has nulls. Plausible-looking numbers, wrong math, decisions made on top of them.

Anchoring generation on a saved and reviewed base query narrows the first two, because the join keys and column names come from SQL a person already checked. It does not settle the third. An executable SELECT can still answer the wrong question, and no validator catches that.

A saved-query library helps wherever your analytical patterns repeat. Revenue by segment, retention by cohort, funnel conversion by source: once a person has written and reviewed one of these, it becomes the anchor for the next question in that shape, so the generated SELECT starts from checked join keys instead of guessing them.

On a genuinely new question there is nothing to anchor on. Chion still generates a fresh SELECT, still checks it in code, and still shows you the statement it ran. If the answer is worth keeping, a person saves and reviews it in Studio, and the next question in that shape starts from reviewed SQL.

A library only compounds if someone reviews what goes into it.

Chion fits when: your team already has SQL worth reusing; the database role has to stay read-only and that cannot be a per-connection setting; you want the executed statement recorded beside the answer; PostgreSQL is the database you are asking about. This is the job the AI SQL analyst page describes in full.

One of these four fits better when: you want to self-host and modify the agent yourself, where Vanna is MIT-licensed with hosted and self-hosted paths documented; you need governed definitions across many sources in a Git repository you own, which is TextQL Ontology 3.0; you want editable Python beside the generated SQL, which Julius documents; or you want a local desktop path that keeps credentials on your machine and sends schema names rather than rows, which Text2SQL.ai documents.

Many teams run two of these. One anchors the analysis people act on, the other is for exploring.

Every statement is checked in the application before it reaches your database. The first layer rejects anything that is not a read-only SELECT, so INSERT, UPDATE, DELETE, DROP and ALTER never leave the application. The second runs a forbidden-keyword check over the statement. Execution is then wrapped with a statement timeout and a row limit, and the result is capped at 1,000 rows and 12,000 cells. These are application string and pattern checks, not a PostgreSQL AST parser, and they sit on top of the permissions attached to the role you supply rather than replacing them. The controls are written up under Trust & Security.

Read-only limits writes. It does not stop an expensive scan against your production database, a sensitive column being read by a role that has been granted it, or a prompt-injection attempt in the question. The agent evaluation guide covers what each boundary does and does not cover.

Credentials sit in an AES-256-GCM vault and are resolved per request rather than held in the application.

Vanna. Vanna 2.0 is an MIT-licensed, user-aware SQL-agent framework with permission hooks, audit logs, UI components, and both hosted and self-hosted paths. Its GitHub repository has been archived and read-only since 2026-03-29, while its commercial pricing page is still published (github.com/vanna-ai/vanna and vanna.ai/pricing, checked 2026-08-31). Where Vanna wins: the license, the source, and your own choice of backend. Chion is the managed path, with a read-only execution policy that is not a setting.

Julius. Julius documents live PostgreSQL and other database connectors, recommends a dedicated read-only credential, shows and lets you edit the generated SQL or Python, and publishes its plan pricing (julius.ai/docs and julius.ai/pricing, checked 2026-08-31). Where Julius wins: connector breadth and an editable Python workflow beside the SQL. Chion is narrower on purpose: PostgreSQL, saved-query anchoring, and published result caps.

TextQL. Ana is a cross-source AI analyst, and Ontology 3.0 keeps definitions, queries, permissions, and artifacts in a Git repository you own, with bidirectional sync; current plans include compute-based and custom tiers (textql.com/products/ana, /products/ontology, and /pricing, checked 2026-08-31). Where TextQL wins: governed definitions across many sources, in your own Git. Chion is a lighter Postgres-first workflow with strict non-write execution.

Text2SQL.ai. Safe Mode uses AST parsing, is on by default, and blocks modification and administrative operations, though it can be disabled per connection or per API request; the desktop app keeps credentials local and sends schema names rather than rows to the cloud (text2sql.ai/docs/security-measures, /desktop, and /docs/connections, checked 2026-08-31). Where Text2SQL.ai wins: an AST-based check, a local desktop path, and dialect breadth. In Chion, read-only is a product policy with no per-connection override.

Visible generated SQL and read-only credential guidance are common across this category. The dimensions worth comparing are whether the read-only path can be switched off, what a single result is capped at, and where the reusable logic lives when you change tools.