Vanna AI alternative: open-source text-to-SQL vs a finished product

Vanna AI vs Intellrise at a glance

• What it is — Vanna: an open-source (MIT) Python framework you install with pip and embed in your own application; the repo describes it as "Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval". Intellrise: a hosted product you log into and connect a data source to.
• Who operates it — Vanna: you. You host the agent, wire it into FastAPI or Flask, and run it in your own infrastructure. Intellrise: we do; you connect a read-only user and start asking questions.
• How it learns your data — Vanna: as of the current 2.0 docs, automatically. Vanna states the agent "learns your database schema, business logic, and query patterns without manual training", and documents Tool Memory, where "every successful interaction is saved" and reused on similar questions. The older `vn.train()` workflow with DDL and question–SQL pairs is presented in Vanna's migration guide as the 0.x way, replaced by system prompts, context enrichers and RAG tools. Intellrise: the AI auto-annotates your schema and learns column and table meanings from ordinary chat, and saves each one as a definition you can read, edit or override, with a dbt mode.
• Model choice — Vanna: bring your own; documented support includes OpenAI, Anthropic, Ollama, Azure, Google Gemini, AWS Bedrock and Mistral. Intellrise: bring your own key too — Gemini, OpenAI, Anthropic, DeepSeek, MiniMax or any OpenAI-compatible endpoint. Neither locks you to a house model.
• Databases — Vanna: PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, SQLite, Oracle, SQL Server, DuckDB and ClickHouse, per its README. Intellrise: 10 sources (PostgreSQL, MySQL, SQL Server, Redshift, BigQuery, Snowflake, Databricks, Google Sheets, CSV, Excel) plus cross-source JOIN and UNION through a DuckDB federation layer.
• Interface — Vanna: a pre-built <vanna-chat> web component that works with React, Vue or plain HTML, streaming SQL, tables, Plotly charts and summaries — a strong starting point you then shape into your own app. Intellrise: a finished analyst UI with persistent dashboards, editable reports and read-only share links on Pro.
• Deliverables — Vanna: the answer arrives in your chat surface, and anything beyond that you build. Intellrise: editable reports and artifacts exported to PDF, DOCX, PPTX, Excel and CSV, plus one-off email delivery on Pro.
• Cost — Vanna: the framework is free and MIT-licensed; Vanna's pricing page lists Explorer at $50/mo with 20 questions/day, Team at $500/mo with 300 questions/day, and Enterprise custom with unlimited questions, plus a stated 20% annual discount. Daily limits reset every 24 hours and requests are rate-limited until the next reset. Intellrise: Free $0, Pro $29/mo (about $24/mo annual), no per-question meter — you pay your AI provider directly on your own key.
• Best for — Vanna: teams who want to embed text-to-SQL inside their own product, keep everything in their own infrastructure, and have the engineering time to own it. Intellrise: analysts, analytics engineers, dbt users and data consultants who want the capability finished, without giving up model or data control.

Vanna AI is archived — what that actually means, and what to do next

If you arrived here because you opened the repository and saw the archive banner, this section is the answer, and the first thing to say is that the situation is less dramatic than the banner makes it look. Here is exactly what is and is not true, all of it re-checked on 30 August 2026.

What is true: github.com/vanna-ai/vanna is a public archive. The banner reads "This repository was archived by the owner on Mar 29, 2026. It is now read-only." The GitHub API confirms archived: true, with the last code push on 2 February 2026 and the last release, v2.0.2, published the same day — a changelog consisting of one ChromaDB fix. There were 289 open issues and pull requests when we checked — 227 of them issues — and a read-only repository can neither accept new ones nor merge a pull request. Nothing in the vanna-ai organisation's other 23 repositories has been pushed since 14 February 2026, and none of them is described as a successor to Vanna. Of the ten most-starred of the 2,496 forks, the top one has 4 stars, so no community fork has visibly taken over either — though ten is all we checked, and a busy unstarred fork would not show up that way. Fork and star counts re-read first-hand on 2 September 2026.

What is not true, and this is the part most write-ups get wrong: the company has not gone away, and the product is still being sold. vanna.ai returned HTTP 200 on 30 August 2026, and vanna.ai/pricing still lists Explorer at $50/mo with 20 questions/day, Team at $500/mo with 300 questions/day, Enterprise custom with unlimited questions, and a 20% annual discount — identical to the figures we recorded on 29 July. The docs are live and unchanged. So this is an archived repository attached to a live commercial product, not an abandoned company. If you are paying for Vanna Cloud, nothing about the archive says your service is ending.

One detail worth flagging because it changes how you should evaluate any advice you read: the README does not mention the archive at all. We swept the full 9,578-byte README on 30 August 2026 for archived, no longer maintained, maintenance mode, deprecated, read-only and successor, and got zero matches (positive control on the same sweep: vanna 52, sql 15). It still opens with "Vanna 2.0: Turn Questions into Data Insights", and an "Enterprise Support — support@vanna.ai" section still sits 281 lines in. The only migration language in it points inward, from 0.x to 2.0. If your source is the README — or an LLM that was trained on it — you will not learn that the repository is frozen. The banner is generated by GitHub, not written by the project.

• Where an archive actually bites is not the part you would guess, and it splits in two. The code half is the easy half: the text-to-SQL logic is pinned MIT source, and it will keep doing exactly what it did on 2 February 2026. What breaks around it is the perimeter — a database driver that publishes a new major version, a model provider changing its SDK, a Python release your pinned dependency set will not build against, or a CVE in something transitive. Every one of those announces itself with a stack trace. Under active maintenance they are somebody else's afternoon. Now they are yours.
• The other half does not announce itself, and it is the half a pinned commit cannot protect. Vanna 2.0 is a RAG-and-LLM agent, so an answer is not produced by the frozen code alone — it comes back from a model endpoint you configure, and that endpoint moves on the provider's release schedule rather than on yours. OpenAI's deprecations page, read 31 August 2026, says it regularly retires older models and that software relying on them “may need occasional updates to keep working”; Anthropic's model-deprecations page, read the same day, says deprecated models stay functional but “are likely to be less reliable than active models”. A retired model is loud — the call fails and you find out immediately. A model that has merely got worse at your schema is silent: you get a different query and a confident number, and nothing errors. We have published our own instance of that on our demo page — the same model, the same four questions through our own prompt and tools, counted cancelled orders as revenue and put a yearly total 4.77 per cent high without raising anything. Under maintenance, somebody re-tunes prompts and retrieval when a model moves. On an archive, nobody does, and nothing tells you it happened.
• Option one: keep it and own the fork. MIT licensing means you can fork, patch and ship without asking anyone. If you already run Vanna in production, this is often the cheapest correct answer — pin your versions, take a fork under your own organisation, and budget a few engineer-days a year for driver and SDK churn. You are not inheriting an unmaintained codebase so much as inheriting one that has stopped moving — an easier problem for the parts that are only code, and a harder one for the part that depends on a model you do not control.
• Option two: move to Vanna Cloud. It is the same team and the commercial tiers are live at the prices above. This is the right call if what you liked was Vanna's behaviour rather than owning the code, and if 20 or 300 questions a day fits your volume.
• Option three: another open-source project that is still moving. If you chose Vanna because it was open source rather than because it was Vanna, look at Wren AI before you look at anything hosted, including us. Its engine — an MDL semantic layer, governed text-to-SQL, an MCP server, a CLI and 22+ connectors — is Apache-2.0 and self-hostable, and it is still shipping: release 0.60.1 was published on 28 August 2026, read first-hand on 2 September. Two things to weigh, both from Wren's own pages. It is open core, and the open-source edition is described on Wren's pricing page as "Built for developers; no UI." — the chat interface, dashboards, agentic mode and row-level security are the commercial half, with Wren AI Cloud starting at $259/mo. And the Docker-based chat-first app that most 2025 tutorials walk you through is not the current code: it is parked on the legacy/v1 branch, renamed Wren GenBI Classic. If your requirement is "still open source and still maintained", that is the closest live shape to Vanna, and we have written up where Wren beats us and where it does not.
• Option four: move to a finished product. This is the honest place to say that this page is published by one — Intellrise — so weigh it accordingly. The case for it is narrow and specific: you were self-hosting to keep control of your model key and your data, not because you wanted to operate a service. If that is you, the comparison in the rest of this page is the relevant one, and the two things you were protecting stay protected, because bring-your-own-key is on every tier including the free one.
• Option five, which we mention because it is genuinely reasonable: do nothing yet. An archived repository is not an outage. If Vanna works for you today, pin it, set a calendar reminder to re-check in six months, and spend the migration budget on something that is actually broken.

1. Bring-your-own-key: keeping what open source already gave you

The usual trade when you move from an open-source library to a hosted product is that you hand over the model. The vendor picks the provider, meters your usage, and your data now flows through their key. For someone who deliberately ran Vanna with their own OpenAI, Anthropic, Ollama or Bedrock credentials, that is a real downgrade, and it is the single most common reason technical teams stay on the library even when maintaining it costs them more than it is worth.

Intellrise does not ask for that trade. It is bring-your-own-key on every tier, including the free one: you connect your own Gemini, OpenAI, Anthropic, DeepSeek, MiniMax or any OpenAI-compatible endpoint, choose the model per conversation, tune context window, output tokens, temperature and reasoning level per key, and pay your provider directly for tokens. There is no per-question meter between you and your model, so a heavy analysis week does not become a billing event. Your business data is never used to train our models — we keep no standing copy of what you connect — PostgreSQL, MySQL and Redshift sources are attached read-only and queried in place; SQL Server, Snowflake, BigQuery and Databricks are read into memory for the session instead, and a Google Sheet is re-read each session — and the rows an answer returns stay in your own account until you delete them — and connection details and keys are encrypted at rest with AES-256-GCM. If you are self-hosting mainly to keep control of cost and data rather than because you want to maintain a service, this is the part worth checking first.

2. Two layers that both learn — one of them is editable

This is the section where an alternative page usually cheats, so here is the correction first. Vanna used to require curation: the 0.x workflow was `vn.train()` with DDL, documentation and question–SQL pairs. That is no longer how Vanna describes itself. The current docs say the agent "learns your database schema, business logic, and query patterns without manual training", and Tool Memory saves every successful interaction and reuses it on similar questions. Vanna's migration guide lists the old training call as the 0.x approach, replaced by system prompts, context enrichers and RAG tools. If you read an older comparison claiming you must hand-build a training set for Vanna, it is out of date — and so was an earlier version of this page.

So the difference is not learning versus not learning. It is what the learned thing looks like and whether you can correct it. Tool Memory, as documented, accumulates successful question-and-tool examples that get retrieved for similar questions. Intellrise accumulates something different in shape: named definitions bound to specific tables and columns. The AI auto-annotates them when you connect a source, and when you clarify a field in ordinary conversation — "net revenue excludes refunds" — it proposes saving that as an Accept or Reject card. Accepted definitions persist, are put in front of the model on every future question, and can be read and rewritten by hand — they are context it is told to use rather than a rule it cannot get around, which is worth knowing before you rely on one. You can point it at a dbt target schema instead, where it recognises fact_, dim_ and stg_ conventions.

Which of those you want is a genuine preference rather than a scoreboard. Retrieval over known-good examples is strong exactly where you have a body of past questions; a written definition is strong when a term is contested and someone needs to see what the tool believes and change it. If your problem is "three people define active customer differently", the editable definition is the thing that settles it.

The other half of trust is being able to see the working. For anything non-trivial Intellrise shows a readable query plan first — sources, fields, joins, filters, groupings, aggregation, in business terms with the raw SQL one click away — and you Execute or Adjust. A read-only guard refuses write statements such as DROP, DELETE, UPDATE and INSERT. One limit on that, because it decides how much the audit trail is worth to you: the plan appears for multi-table, cross-source and multi-step questions. For ones the model judges simple — one table, one aggregation, a basic filter — it runs the query straight away, and it is the model that decides which kind yours is. A chart you pin re-runs its stored SQL rather than asking the model again, so what you get is not a promise that the answer never changes; it is the query in front of you, and an audit trail you can hand to whoever asks where the number came from.

3. From question to deliverable, without assembling the pieces

Vanna ships a genuinely useful <vanna-chat> component that streams SQL, a data table, a Plotly chart and a summary, and drops into React, Vue or plain HTML. It is a strong starting point. But it is a starting point: the persistent dashboard, the saved report your finance lead can edit, the PDF that goes into the board pack, the share link for someone without a login — those are things you design and build on top, and they are usually where the sprint estimate quietly triples.

Intellrise is end-to-end by construction. The same conversation produces inline charts for exploratory questions, Metabase-style dashboards you can pin to from chat and — on Pro — drag, resize and recolour, and report artifacts by type — a data grid for Excel and CSV, a 16:9 deck for PPTX, a document for PDF and DOCX — rendered in an in-chat side panel, kept as a draft until you save it, then editable in place. Read-only share links and one-off email delivery are available on Pro. It is the difference between having the engine and having the car, and for a small data team the honest question is whether building the rest of the car is the best use of the next month.

When Vanna is the better choice

Plenty of the time, it is. If you are embedding natural-language querying inside your own product, Vanna is the right shape and Intellrise is not — a hosted analyst app is not a component you can ship to your customers. If your security posture requires that nothing, including metadata, leaves your own infrastructure, self-hosting is the answer and no SaaS will match it. If you need per-user row-level filtering enforced inside the agent, Vanna 2.0 describes itself as "a complete rewrite focused on user-aware agents and production deployments", and separately documents queries being "automatically filtered per user permissions" — it addresses that directly, and Intellrise does not.

It is also better whenever control is the point. You can read every line, fork it, swap the retrieval layer, run a fully local model through Ollama, connect a database nobody else supports, and change the prompt when you disagree with it. MIT licensing means none of that is anyone's decision but yours. And if you already have curated question–SQL pairs, that investment is real accuracy that a general product has to earn from scratch. Choosing open source is a reasonable, often correct engineering position, and having the engineering time to back it is a legitimate advantage — not something to apologise for.

The build-versus-buy question, honestly

The cost of the library is not the cost of the system. Running Vanna in production means hosting the agent, standing up and backing up the store its knowledge lives in, owning the retrieval quality, building the interface, and then maintaining all of it while the model landscape moves underneath you. Teams who want exactly that get a lot in return. Teams who wanted a working analyst and ended up with an internal platform to maintain usually feel it about three months in.

One factual point worth knowing if maintenance matters to your decision: the main vanna-ai/vanna repository on GitHub is marked as a public archive. Its own banner reads "This repository was archived by the owner on Mar 29, 2026. It is now read-only", and the last push recorded by the GitHub API is 2 February 2026. The code remains MIT-licensed, freely usable and forkable, the commercial product and enterprise support are actively offered, and a large body of production deployments and community integrations exists — so this is not a reason to avoid it. What it changes is the shape of the maintenance question: it moves from "will they fix it" to "can we fix it ourselves", which for a team that chose open source on purpose may be an acceptable answer rather than a problem.

Intellrise takes the other side of that trade on purpose. There is nothing to host, nothing to train and no UI to build, and the two things you would most hate to lose — your model key and your data — stay yours.

Who Intellrise is for

Intellrise fits the same technical audience Vanna attracts, at the point where they would rather use the capability than operate it. Analysts, analytics engineers, dbt users, data consultants and technical founders tend to feel the difference first: a semantic layer that learns their schema without a curated training set, a readable query plan they can audit, cross-source joins over 10 connectors, bring-your-own-key economics, and reports they can actually hand to a stakeholder. If your data lives in a warehouse, a recurring question needs to become a saved query you can re-run and diff rather than code inside a chat, and the deliverable matters as much as the answer, that is the case for buying rather than building.

Try it on your own data

The honest way to decide is to run one of your real questions and see what comes back. Every new Intellrise account starts on a 14-day Pro trial with no card, and there is a public demo that needs no signup and no AI key — a synthetic sample dataset, the queries verbatim, and the charts they return — so you can judge the query plan and the output before connecting anything of your own. After the trial the free tier stays free: one database source plus Google Sheets, three dashboards, and unlimited reports and exports. Pro is $29/mo, or about $24/mo billed annually.