Best text-to-SQL and chat-with-your-database tools in 2026

The six categories, in one place

• Open-source frameworks you run yourself — Vanna AI, Wren AI. You host it, you bring the model key, you own the semantics. Maximum control, maximum work.
• Open-source BI with a natural-language layer — Metabase (Metabot). An assistant inside a BI tool you may already run.
• Warehouse- and platform-native assistants — Snowflake Cortex Analyst, Databricks AI/BI Genie. Natural language on data already inside that platform, governed by that platform, billed on that platform's meter.
• Enterprise BI copilots and analytics agents — Copilot in Power BI, ThoughtSpot Spotter. Natural language over a curated, governed semantic model, sold with the wider BI suite.
• Dedicated chat-with-your-database products — AskYourDatabase, Intellrise. Standalone tools whose whole job is question in, answer out, on databases you connect.
• General AI assistants and file-first analysts — ChatGPT, Claude, Julius AI. Excellent reasoning over files you hand them; not built to sit on a live production database.

Every tool at a glance: where it runs, who holds the key, what it costs to start

The two questions above — who supplies the model key, and what you actually get billed for — separate these products faster than any feature list. Here they are side by side. Every figure is the entry point, not the full price list, and several of these carry a platform meter on top of the number shown.

How to judge a text-to-SQL tool: eight criteria that actually matter

Demos all look the same. These are the questions that decide whether a tool survives contact with your real schema.

• Reproducibility — ask the same question next Tuesday and do you get the same number? None of these vendors publish a run-to-run variance figure, so treat this as something to test rather than something to read off a table. What you can check up front is the mechanism: a tool that leaves you a saved query definition attached to a source gives you something to re-run and diff, whereas a tool that leaves you generated code inside a conversation gives you something to go and find. If a number will end up in a board pack, this is the first thing to test.
• Who holds the AI key, and who pays for tokens — bring-your-own-key means you pay the provider directly and control the model and spend. A platform key means predictable-looking plans but a meter (messages, credits, questions per day, or capacity units) between you and your answers. Neither is wrong; know which one you are buying.
• Where the semantics live and who maintains them — a hand-written modelling layer (Wren's MDL, a Snowflake semantic view, a Power BI semantic model) is precise and auditable, but somebody has to write and maintain it. A tool that learns definitions from usage is lower effort but you should be able to inspect and correct what it learned. "No semantic layer at all" is the option that quietly produces wrong numbers.
• Does schema understanding persist — does a correction you make today survive into next month's conversation, or do you re-explain "net revenue excludes refunds" every session? This is the difference between building an asset and repeating yourself.
• Connector breadth, and whether it is the right breadth — a warehouse-native assistant covers one platform perfectly. A standalone tool covers many, sometimes shallowly. Count the sources you actually need, including the awkward Google Sheet nobody will migrate.
• Read-only safety — can the tool physically not write? Look for a SELECT-only guard in the product and, independently, connect with a read-only database role. Never rely on the prompt to keep an LLM away from DELETE.
• What you can do with the answer afterwards — a chart in a chat window is where most tools stop. Ask whether you get a persistent dashboard, an editable report, and a file you can email to someone who will never log in. This is often the gap between "impressive" and "used weekly".
• Deployment and data boundary — self-hosted, vendor cloud, or in-warehouse? For regulated or sensitive data, this often decides the shortlist before any feature comparison starts.

Category 1 — Open-source frameworks you run yourself

These are libraries and engines, not finished products. You get source code, full control of the data boundary, and no per-question meter — in exchange for hosting, wiring and maintenance. Pick this category if you are embedding natural-language querying into your own application, or if your data cannot leave your infrastructure.

Vanna AI — the embeddable text-to-SQL library

Vanna is an MIT-licensed Python package for building a SQL agent: you install it, give it context about your database, and it turns questions into SQL, runs them, and returns tables, charts and summaries. Its README advertises deliberately broad compatibility — OpenAI, Anthropic, Ollama, Azure, Google Gemini, AWS Bedrock and Mistral on the model side, and PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, SQLite, Oracle, SQL Server, DuckDB and ClickHouse on the data side.

Because it is a library rather than an application, the result depends heavily on the interface you build around it. On context, note that the current 2.0 docs claim the agent "learns your database schema, business logic, and query patterns without manual training", with Tool Memory saving successful interactions — so the older "you'll have to hand-curate a training set" characterisation of Vanna is out of date. Its pricing page also lists hosted plans (Explorer at $50/month with 20 questions/day, Team at $500/month with 300 questions/day, a 20% annual discount, and custom Enterprise pricing including on-premises deployment), which mainly buys you the admin layer rather than a different engine.

One thing to check before you build on it: as of 29 July 2026 the GitHub repository is marked archived, with its last push in February 2026, while the Vanna Cloud plans above are still being sold. We state that neutrally because the code is MIT-licensed and 23,000-plus stars of prior work does not stop functioning — plenty of teams run forks of archived libraries quite happily. But an archived upstream changes the maintenance question from "will they fix this" to "can we fix this ourselves", and that belongs in the decision rather than in a footnote.

Best for: engineering teams putting natural-language querying inside their own product, and anyone who needs the whole stack to run in their own infrastructure with their own model key. Not the right pick if you want dashboards, reports and user management out of the box — that is your job here.

Wren AI — open-source GenBI with a modelling layer

Wren AI is a more complete open-source system: an engine that resolves a question against a semantic layer and returns SQL across 20+ data sources including BigQuery, Snowflake, PostgreSQL, ClickHouse, Redshift and Databricks. The repository is multi-licensed by path — Apache 2.0 for the core, SDK and examples, CC BY 4.0 for the docs — and is designed to be self-hosted and LLM-agnostic, with the pricing page listing bring-your-own-LLM on the open-source edition.

Check which Wren you are looking at before you evaluate it, because the project restructured in 2026. The engine merged into the main repository under core/ on 4 May 2026, and the open-source edition is now developer-first: its own pricing page describes it as "Built for developers; no UI." The older chat-first BI application many write-ups still describe is preserved on the legacy/v1 branch as Wren GenBI Classic, with no new features or security fixes. If you want charts and dashboards out of the box rather than an engine to build on, that difference matters more than any feature comparison. If you are citing that merge date, note that Wren's own sources give it three ways: the README banner is stamped "2026-05-07", the announcement it links to puts the import merge on 5 May and the archiving of the old repository on 7 May, and every commit touching core/ in that window lands on 4 and 5 May with none at all on 7 May. We use 4 May because that is what the commit record shows.

Its distinguishing idea is the Modeling Definition Language, which Wren's own docs call "the semantic contract at the center of Wren AI" — an explicit definition of what Wren's docs list as its core MDL objects: models, columns, relationships, calculated fields, views and cubes. Their framing is the clearest statement of this whole design philosophy: raw schemas describe storage, MDL describes meaning. That is a real strength — your semantics are code, reviewable in a pull request, and the AI is bounded by them rather than guessing. It is also the cost of entry, because somebody has to write and maintain that model.

The hosted editions are priced publicly: a free cloud tier with 20 credits a month, Essential Cloud at $179/month billed annually with 13,200 annual credits, Enterprise Cloud at $559/month billed annually with 24,000, and a self-hosted Enterprise Plus tier with no published number. Month-to-month those two tiers are $259 and $799 — the pricing page opens on the annual toggle, so the lower pair is what you see first. Overage is $0.10 per credit. The plan cards also advertise "Credits roll over up to 2x", but Wren's own FAQ on the same page limits that to monthly billing — "unused credits in an annual plan do not roll over across billing cycles" — so it does not apply to the annual prices quoted here. Wren figures re-read 3 August 2026.

Best for: data teams who want governed, self-hosted natural-language querying and are comfortable maintaining a modelling layer in version control. If you have the discipline for it, this is one of the most rigorous options on the list and the open-source edition costs nothing to run but your infrastructure and tokens.

Category 2 — Open-source BI with a natural-language layer

If a BI tool is already deployed and people log into it every day, an assistant inside that tool has an unfair advantage: zero new surface area, existing permissions, existing charts.

Metabase (Metabot) — an assistant inside the BI tool you may already run

Metabot is Metabase's AI assistant. Per Metabase's documentation it creates charts from natural language, generates and edits SQL in the native editor, fixes query errors, analyses existing visualizations, generates transforms and answers questions from Slack. Metabase's pricing page lists AI SQL generation in the free Open Source column, with some capabilities reserved for paid tiers — admins on Pro and Enterprise can restrict Metabot to verified models and metrics, and letting your own customers ask questions with AI, along with AI usage auditing and controls, sits on Pro.

Two details make it notable in this roundup. First, it is bring-your-own-key: Metabase's own feature page says you plug in the provider you already use — Anthropic, OpenAI, AWS Bedrock or Microsoft Azure — and on self-hosted deployments you configure your own provider so everything stays in your environment. Second, Metabase is candid in its docs about the limits, including the standing advice to double-check generated results.

Best for: teams already running Metabase, especially self-hosted. The assistant inherits your existing models, permissions and audience, which is worth more than a marginally better question-to-SQL engine somewhere else.

Category 3 — Warehouse- and platform-native assistants

If all of your data already lives in one platform, the platform's own assistant is the shortest path: no new connector, no new copy of the data, no new governance model. The tradeoffs are symmetrical — you are limited to that platform's data, that platform's models, and that platform's meter.

Snowflake Cortex Analyst — natural language on Snowflake data

Cortex Analyst is Snowflake's managed natural-language-to-SQL feature for structured data in Snowflake, exposed as a REST API you embed in Streamlit, Slack, Teams or your own chat interface. Snowflake's documentation is unusually clear about the accuracy story: schemas alone lack business context, so semantic models are strongly recommended, with Semantic Views now the preferred approach over the older YAML-on-a-stage method.

It runs on Snowflake-hosted models — the docs name Anthropic Claude Sonnet, OpenAI GPT-4.1, Arctic Text2SQL, and a Mistral Large 2 / Llama 3.1 70b combination — so there is no bring-your-own-key. Billing is credits per processed message, plus the warehouse compute for actually running the generated SQL. And it works on data in Snowflake, full stop.

Best for: Snowflake-centric organisations that want an accurate, governed natural-language interface and are willing to invest in semantic models. If half your data sits outside Snowflake, this answers half your questions.

Databricks AI/BI Genie — natural language on the lakehouse

Genie is Databricks' natural-language experience: one place to ask data questions, explore AI/BI dashboards and run Databricks Apps, with answers grounded in your organisation's data and governed through Unity Catalog. Rather than a hand-written modelling language, you shape accuracy by configuring datasets, sample queries and instructions, and by adding metrics, business rules and verified answers to build a trusted environment.

Commercial terms are in motion and worth checking directly. Databricks' documentation describes Genie Code moving to pay-as-you-go from 8 July 2026 with a per-user monthly free allowance, and Genie One and Genie Agents usage free through 31 July 2026, with budget and cost controls for account admins. Note the date on that second one: it lapses on 31 July 2026, and the docs do not say what replaces it, so read the current pricing page rather than assuming either that it stays free or that it becomes paid.

Best for: teams already on Databricks with Unity Catalog governance in place. The verified-answers pattern — curating known-good responses to common questions — is a genuinely good idea that most tools in this roundup lack.

Copilot in Power BI — natural language over a curated semantic model

Copilot in Power BI covers both ends: business users chatting with a report or across items they have access to, and report authors generating reports, DAX queries and measure descriptions. When a question relates to data in the semantic model, Copilot answers from that model; otherwise it falls back to the language model's general knowledge — a distinction worth understanding before you trust an answer.

The requirements are the main gate. Microsoft's documentation is explicit that Copilot needs a paid Fabric capacity (F2 or higher) or Power BI Premium (P1 or higher); a Power BI Pro or Premium Per User licence alone is not sufficient, and trial capacities are unsupported. Consumption shows up as capacity units in the Fabric Capacity Metrics app. Microsoft also states plainly that model owners must prepare their semantic models for AI, warning that without that preparation Copilot can produce generic, inaccurate or misleading output.

Best for: organisations already standardised on Power BI or Fabric with well-modelled semantic models and capacity to spare. It is the wrong starting point for a small team with a raw Postgres database and no BI estate.

ThoughtSpot Spotter — the enterprise analytics agent

Spotter is ThoughtSpot's analytics agent, aimed at enterprises that want self-service analytics under governance. Notably, it does not emit raw SQL directly — ThoughtSpot's own wording is that "instead of direct text-to-SQL, Spotter translates questions into search tokens grounded in your governed semantic layer—producing fully traceable, auditable queries." That is a genuinely different architecture from most of this list, and the reason it appears in a text-to-SQL roundup at all is that it answers the same question for the buyer. It also reaches beyond answering, triggering actions in systems such as Jira, Salesforce and Slack.

It assumes the enterprise prerequisites: a maintained semantic layer, connected cloud sources, and a governed analytics platform underneath. It does publish list prices, which is worth knowing because enterprise BI usually does not: Essentials starts as low as $25 per user per month billed annually for 5 to 50 users and up to 25M rows, and a usage-based Pro tier starts as low as $0.10 per credit for up to 1,000 users and 250M rows, with Enterprise and Embedded Enterprise quoted rather than listed. Spotter itself is listed as a Pro-tier feature.

Two details cut against the assumption that platform-scale means platform lock-in on the model. ThoughtSpot states that LLM tokens are unlimited and that it does not meter or charge for them, and it supports pointing Spotter at your own LLM provider, in which case that provider's fees apply. On the key question of who holds the model relationship, this is closer to the bring-your-own-key end of the list than its enterprise positioning suggests.

Best for: larger organisations that already have — or intend to build — a governed semantic layer and want auditable, action-taking analytics across many business users.

Category 4 — Dedicated chat-with-your-database products

These are standalone products whose entire purpose is question in, answer out, on databases you connect. They do not assume you own a warehouse platform or run a BI estate, which makes them the practical middle ground for small teams, consultants and individual analysts.

AskYourDatabase — desktop app and embeddable database chatbot

AskYourDatabase positions itself as a SQL chatbot for chatting with a database. Its connect documentation lists MySQL, PostgreSQL, SQL Server, BigQuery, Snowflake and Vertica, and documents MongoDB and ClickHouse as well — a list that includes MongoDB and Vertica, which most tools in this roundup do not. Its home page also shows Oracle, though that documentation page does not mention it, so confirm Oracle directly if it is your deciding factor. It ships in two shapes: a desktop application that keeps data local to the device, and a website chatbot you can embed for customers, with on-premise deployment offered to enterprise customers.

Pricing is published and reflects those two shapes. The desktop Ultimate plan shows $69.99/month struck through to $49.00/month per seat, and the page states this is a countdown promotion about to end — the same figure appears on both the yearly and monthly toggles, so treat $49 as a temporary price and $69 as the one to budget for. It lists unlimited access to specific hosted models. The embeddable chatbot starts at $149/month for 1,000 questions and up to 6 chatbots, $329/month for 1,500 questions with unlimited chatbots and custom branding, and custom Enterprise pricing with on-premise hosting. The pricing page lists neither a free tier nor a bring-your-own-key option, so plan on the vendor's models and the vendor's meter — though the site does mention a free quota on a small model elsewhere.

Best for: teams that need a wide connector list including MongoDB, ClickHouse or Vertica, and especially anyone whose goal is to embed a data chatbot for their own customers rather than to run internal analysis.

Intellrise — end-to-end analyst with a semantic layer whose error rate we publish

Intellrise is a standalone AI data analyst in the same category as the entry above, with two things it leads on. First, it is end-to-end: one plain-English question produces a query, a chart, and then a persistent dashboard or an editable report you can export to PDF, DOCX, PPTX, Excel or CSV — rather than a chart that lives only in a chat window. Second, the semantic layer annotates itself and then keeps the corrections you make: the AI describes your schema on connect, learns column and table meanings from your conversations and keeps them across sessions and schema refreshes, with a dbt mode and a manual editor. That is the same accuracy problem Wren solves with a hand-written modelling language and Snowflake solves with semantic views, approached from the other end — lower effort to start, and you inspect and correct rather than author from scratch. This entry used to say the layer "maintains itself" and leave it there, which is a claim about accuracy with no accuracy figure attached — on a page that dates a competitor's repository archive to the day. So the next paragraph is the measurement instead of the adjective, including the three things it got wrong.

What the annotation step actually got right and wrong, measured on 15 August 2026: we pointed the product’s own annotation step at a deliberately nasty Postgres — 30 tables, 253 columns, 8,337 rows, 44 foreign keys and not one COMMENT ON, the shape a schema takes after a decade of nobody documenting it — and read every line it wrote. Coverage was complete: 30 of 30 tables and 253 of 253 columns described in a single pass. It got the housekeeping right with no prompting: it identified the soft-delete flag, called ord_ln.total an “Extended line total” rather than an order total, marked all three abandoned backup and staging tables as abandoned, and worked out from three sample rows that pymt_hdr.ref_no hides an invoice number inside a text field. It also got three things wrong and flagged none of them: it reversed the meanings of two date columns, and stayed wrong in all 400 rows we checked; it never noticed that one amount column was tax-inclusive and its sibling was not, though the median ratio between them was 1.0765; and it gave a 0.02–0.04 decimal column and a 4.00–12.75 percentage-point column descriptions that both call the number a percentage — “Commission percentage rate” and “Tax rate percentage” — a hundredfold difference in scale that neither description distinguishes. Three wrong out of 253 described is the flattering way to put that and also the wrong one: every one of the three is about a relationship between two columns, six columns in all, and what decides whether this is safe for you is not the ratio but whether the handful of columns your reported figures depend on are among the ones it misread — which is why we are not quoting a percentage. So the honest shape of this feature is not “it understands your database”. It is that the layer does the reading nobody wants to do, gets the structural conventions right, and cannot guess the handful of things nobody could guess from column names — which date counts, whether that amount includes tax, whether that pct is a fraction or a percentage. Those you tell it once, in chat, and it keeps them.

Mechanics: 10 sources (PostgreSQL, MySQL, SQL Server, Redshift, BigQuery, Snowflake, Databricks, Google Sheets, CSV, Excel) that one question can combine — your Postgres orders table joined to the Google Sheet of targets nobody will ever migrate — because all ten are queried through a single engine (DuckDB) instead of each source only being able to see its own tables; a readable query plan in business terms before complex queries run, with the SQL one click away; a read-only guard that refuses write statements such as DROP, DELETE, UPDATE and INSERT — eighteen keywords, checked as text rather than parsed, which is why the read-only database role below it is the control we would rather you relied on; credentials and keys encrypted with AES-256-GCM. It is bring-your-own-key across Gemini, OpenAI, Anthropic, DeepSeek, MiniMax or any OpenAI-compatible endpoint, so you pay your provider directly for tokens and your business data is never used to train our models. Pricing is Free $0 (one database source plus Google Sheets, three dashboards, unlimited reports and exports) and Pro $29/month, about $24/month billed annually. Every new account gets a 14-day Pro trial with no card, and there is a public demo at intellrise.com/demo showing the dataset, the SQL and the resulting charts without any signup.

The honest limits: the first pass of annotation will write some business meanings confidently wrong, as above, and the product does not yet mark the entries it was unsure about — so the right first move after connecting a source is to read the semantic layer once rather than trust it. There is no shared team workspace, seats or roles yet — it is a single-user product today, so a department that needs shared ownership should look at the BI-native options. Email delivery of a report is send-now only; there is no scheduled or recurring delivery. Free-form chat requires you to supply an AI provider key, which is fine for analysts and awkward for non-technical users. And it is a small, young product next to the platform vendors on this list, with a correspondingly small community. On the measurement above: it ran the product's own adapter and its own verbatim annotation prompt on gemini-3.1-flash-lite against a real Postgres we built to be messy, not through the web app and not on a customer database — so read it as a measurement of the annotation step, not of an end-to-end session.

Best for: analysts, analytics engineers, dbt users, data consultants and technical founders who need a saved query definition they can re-run and diff on live databases, cost control through their own key, and an exportable artifact at the end — without standing up a warehouse platform or maintaining a modelling layer by hand.

Category 5 — General AI assistants and file-first analysts

These are the tools most people actually reach for first, and for one-off work they are frequently the right answer. They belong in this roundup precisely so you can tell when they are, and when they are not.

ChatGPT and Claude — strongest reasoning, and both now reach a database

For analysing a file you already have, a general assistant is hard to beat: upload a spreadsheet, ask in plain English, get a chart and an explanation, and keep going with follow-up questions that mix analysis, writing and code. The reasoning quality is the best available.

This section used to say neither of them could reach a live database. That is no longer true, and it changed while this page sat here saying otherwise, so here is the corrected version with the date on it. Checked 15 August 2026: ChatGPT's own app directory at chatgpt.com/plugins lists Neon Postgres, Supabase and BigQuery — Snowflake, MySQL and Databricks were not in it on that date. Claude's connector directory lists Snowflake and a Supabase connector that describes executing SQL against PostgreSQL. Check the directory for the assistant you actually use rather than trusting any roundup, this one included.

What has not changed is the sandbox and what persists. OpenAI's help documentation states plainly that "the Python environment used for data analysis cannot make external web requests or API calls" (checked 29 July 2026), so analysis still runs on what you upload or what a connector hands over. Two further corrections to the usual version of this argument: ChatGPT does have memory across conversations — OpenAI says saved memories are "always considered in future responses" — and we make no claim about run-to-run variance, because OpenAI publishes no figure for it. The real difference is not reach any more; it is that what persists is generated code in a chat rather than a query definition attached to a source.

Best for: exploratory, one-off analysis of files you already have, and anything that mixes data work with writing or coding. We have a longer, dedicated comparison of this exact tradeoff — see the ChatGPT for data analysis page linked below.

Julius AI — file- and spreadsheet-first analysis

Julius is a polished AI data analyst built around uploading a file and getting a fast, well-presented answer, with a large user community and a wide range of chart types. Like the general assistants, it answers by generating and running code, which is flexible for exploration; it meters usage in credits on the platform's own models rather than a key you supply, and database connectivity sits on paid plans.

Best for: quick, one-off analysis of a spreadsheet or CSV with zero setup, and exploratory work where re-running the same query next week is not the point. We have a dedicated Julius AI comparison page with a fuller treatment — linked below.

How to choose: five common situations

• You want to embed natural-language querying in your own product → an open-source framework. Vanna if you want a library to build around; Wren AI if you want an engine plus a governed modelling layer.
• It is a one-off question about a spreadsheet → a general assistant or a file-first analyst. Do not connect a production database for something you will ask once.
• All your data is in one platform and that platform has an assistant → use it. Cortex Analyst on Snowflake, Genie on Databricks, Copilot if you are standardised on Power BI or Fabric. Nothing beats the native option on governance and setup cost for data that already lives there.
• You already run a BI tool people log into → try its assistant before buying another product. Metabot on Metabase is bring-your-own-key and available even on the free open-source edition.
• You need repeatable answers on a live database, cost control, and something you can send to a stakeholder → a dedicated chat-with-your-database product. This is the category Intellrise is in: connect a read-only source, get a reviewable query plan, keep a semantic layer that learns, and export the result.

What none of these tools do for you

Three caveats apply across the entire list, and any vendor who tells you otherwise — including us — is overselling.

• Semantics are still your responsibility. Whether you write a modelling language, curate a semantic view, or review what a self-learning layer inferred, somebody has to confirm that "revenue" means what the business thinks it means. Every accurate deployment in this space has a human who did that.
• Nothing here removes the need to verify. Metabase says it in its own docs; Microsoft warns that unprepared models produce misleading output. Test with a set of questions whose correct answers you already know, and re-test after a schema change.
• Read-only is on you at the database level. A product-side SQL guard is necessary and not sufficient. Create a dedicated SELECT-only role for any tool you connect, no matter what its marketing says.