Originally published at https://intellrise.com/guides/vanna-ai-alternative/
Disclosure first, because it changes how you should read everything below: we make Intellrise, which is one of the alternatives discussed here. Weigh it accordingly. The way we've tried to earn the read is by publishing the parts that don't help us — including our own measured error rates, further down.
Two kinds of people end up on a page like this. One is technical: you already run Vanna, you opened the repo, you saw the archive banner, and you want to know how bad it is. The other has no database at all, works out of spreadsheets, and got here while trying to figure out what any of these tools do. Both of you are covered; the second group can skip to the last two sections.
What is actually true about the archive
All of this was read first-hand from Vanna's own sources — the vanna-ai/vanna README, vanna.ai/docs, vanna.ai/pricing, and the GitHub REST API — and re-checked first-hand on 30 August 2026.
-
github.com/vanna-ai/vannais 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. The last code push was 2 February 2026. The last release, v2.0.2, was published the same day; its entire changelog is a single ChromaDB fix. -
289 open issues and pull requests were outstanding on 30 August 2026 — 227 of them issues. (GitHub’s
open_issues_countcounts pull requests too, which is why most write-ups quote one number and mean another.) A read-only repository can neither accept new issues nor merge a pull request. - 23,817 stars and 2,491 forks on 30 August 2026. (We also read 23,822 on 1 August and 23,823 on 29 July, but a six-star drift over a month is noise, not a signal — don't let anyone sell it to you as one.)
- There is no successor. Across the 24 repositories in the
vanna-aiGitHub organisation, nothing has been pushed since 14 February 2026, and none carries a description identifying it as a Vanna successor. - No community fork has visibly taken over either. Of the 2,491 forks, the highest-starred one we found on 30 August 2026 has 4 stars (two are tied at four).
And what is not true
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, 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. Those figures are unchanged from our earlier readings on 29 July and 1 August. The docs are live.
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 about this: 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 — zero matches. It still opens with "Vanna 2.0: Turn Questions into Data Insights" and still carries an "Enterprise Support — support@vanna.ai" section, 281 lines in. The only migration language in it points inward, from 0.x to 2.0. If your source is the README — or a model trained on it — you will not learn that the repository is frozen. The banner is generated by GitHub, not written by the project.
A correction that most comparison articles owe Vanna
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.
Its current docs say the agent "learns your database schema, business logic, and query patterns without manual training", and document Tool Memory, where "every successful interaction is saved" and reused on similar questions. Vanna's own migration guide lists vn.train() as the 0.x approach, replaced by system prompts, context enrichers and RAG tools.
If you read a comparison claiming you must hand-build a training set for Vanna, it is out of date — and so was an earlier version of our own page. We got that wrong and fixed it.
Where an archive actually bites
Not where you'd guess. The text-to-SQL logic does not rot; pinned MIT code keeps doing exactly what it did on 2 February 2026.
What breaks 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. Under active maintenance those are somebody else's afternoon. Now they are yours.
Your four real options
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 one that has stopped moving, which for a stable component is a different and easier problem.
Two: move to Vanna Cloud. Same team, live commercial tiers at the prices above. 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.
Three: move to a finished product. We make one, so read the next section with that in mind. The case is narrow: you were self-hosting to keep control of your model key and your data, not because you wanted to operate a service.
Four: do nothing yet. An archived repository is not an outage. If Vanna works for you today, pin it, set a calendar reminder for six months, and spend the migration budget on something that is actually broken. We mention this one because it is genuinely reasonable.
If you're weighing option three, here is the honest version
Intellrise is a hosted product you log in to and connect a data source to. Vanna is a library you install with pip and build around. That is the whole structural difference, and everything below follows from it.
What you keep. 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 flows through their key. Intellrise is bring-your-own-key on every tier including the free one — Gemini, OpenAI, Anthropic, DeepSeek, MiniMax, or any OpenAI-compatible endpoint via a custom base URL, with per-key control over context window, output tokens, temperature and reasoning level. There is no platform key to fall back to and no per-question meter; you pay your provider directly for tokens. Plans are Free $0 and Pro $29/mo, or $290/year (which works out to about $24/mo). Every new account starts on a 14-day Pro trial with no card.
What leaves your network, precisely. On a normal question, what goes to your provider is your question text, your table and column names, and the SQL — the tool receipt handed back to the model is {success, row_count, error}, and result rows go to your browser, not into the prompt. Two exceptions you should know about: AI semantic schema learning sends up to 3 sample rows per table to your own provider when you connect or refresh a source (this is the Pro-gated step, so it does not run on Free), and a Gemini-only degraded retry path can send up to 10 result rows. And the names travel verbatim: the display name you give a source, every table name, every column header, and any description you or the semantic layer saved. For a company with a warehouse those names are fct_orders. For a company running on spreadsheets, where a Google Sheets tab name becomes the table name, those names are the customer list. Renaming tabs helps; it doesn't fully solve it, because the text of your question is sent too.
Read-only, stated exactly. There is a read-only guard that refuses write statements such as DROP, DELETE, UPDATE and INSERT, and it covers SQL the model writes as well as SQL you write. It is 18 keywords of text matching — a keyword guard rather than a SQL parser, which is why the read-only grant on your side is still the control worth having. SET is deliberately not on the list. And we do not check whether the account you hand us is actually read-only; nothing in our backend queries your privileges. On PostgreSQL and Redshift there is a second, structural layer: the connection itself is attached read-only. Some of our other adapters work differently — they read rows into memory and query that copy — so we can honestly say we keep no persistent mirror, but not that we never copy.
Encryption, in two layers that don't cover the same things. Credentials and AI keys are encrypted by us with AES-256-GCM before they reach the database. Your answers are not: message content, query results, reports, pinned charts and uploaded files are plaintext columns, protected by our host Neon's disk-level AES-256 encryption at rest. In plain terms — at the database layer, your credentials are unreadable to us and your answers are readable to us. Neon's SOC 2 / ISO 27001 posture is Neon's, not ours; we hold none of those certifications.
What we don't have. Every tier is single-seat; the Team plan is listed but not purchasable. We do not offer a DPA today — if your procurement requires one, stop here, this is the wrong vendor for you this quarter. The free tier is one database source plus Google Sheets (Sheets don't count toward the limit), three dashboards, no file upload, no share links, no email delivery, and no AI schema learning. All five export formats work on Free, but the document formats truncate: PDF and PPTX render 30 rows, DOCX 100 rows, with a line telling you how many were left out; CSV and Excel are complete. And there is one bug we haven't fixed: on a Google Sheets source, re-selecting which tabs to include wipes every saved definition for that source. We measured it, a fix was drafted and rejected in review because the safer-looking version could mis-attach definitions to the wrong tab, and it is still unfixed in production.
Neither tool understands your business on day one. Here are our numbers.
The thing worth arguing about isn't whose SQL is prettier. It's whether you'd notice when the answer is wrong. So here is what happened when we pointed our own semantic layer at a deliberately messy database — 30 tables, 253 columns, 8,337 rows, 44 foreign keys, and zero COMMENT ON entries, like a real legacy system.
What it got right, in one pass, with nothing but column names and three sample rows per table: all 30 tables and all 253 columns annotated, none skipped. It identified soft-delete flags (del_flg → "Soft-delete indicator"). It correctly called ord_ln.total an "Extended line total" — a line subtotal, not an order total, which is the classic first mistake a new analyst makes. It spotted all three junk tables for what they were (backup, temp staging, old audit log). And from three sample rows it worked out a relationship nobody documented: a payments table with no invoice column, where the link was hidden inside a text field — annotated as "Reference number (e.g., Invoice #)".
What it got wrong — silently, with no flag, in confident English:
- Two date columns were annotated backwards. In the real data one date is always on or after the other, on 400 of 400 rows, which makes the ordering unambiguous. The model labelled the entry-timestamp column as the order date and vice versa. Ask "revenue by order date" and you quietly get the wrong column.
- One amount column includes tax and another doesn't — the ratio between them has a median of 1.0765, against a tax table running 4.00–12.75%. The model described both as "total amount". Both descriptions are true and neither is useful.
- Two
_pctcolumns are on different scales: commission runs 0.02–0.04 (a decimal), tax runs 4.00–12.75 (percentage points). Both were annotated as "percentage". That's a 100× error waiting to happen.
And on a clean five-file demo dataset, running the product's own prompt and tool loop: three of four questions counted 155 cancelled orders as revenue — 597,387.69 against 570,211.28 when the same query is written by hand, a 4.77% overstatement that also swapped one product out of a top-ten list. In two of three runs the model invented a status value that does not exist anywhere in the data (all 2,845 rows carry one value, success), got an empty table back, and the product's own narration then explained the empty table as a fact about the business rather than a bug in its own filter.
Two honest boundaries on those numbers: they come from running the product's own adapters, prompts and tool loop directly, not end-to-end through the HTTP API and front end; and we have not run the same tests against Vanna, so nothing here says we do better than Tool Memory does. It may well do better. What we can say is that we published ours.
The conclusion we draw is not "our model is smarter". It's that this class of error is not fixable by a better model, because the model cannot see what it isn't shown. What matters is whether the correction sticks. When you tell Intellrise in ordinary conversation that net revenue excludes refunds, it offers to save that as a named definition bound to that table and column; accepted definitions are written to a persistent column and loaded into every future session, and you can read them, rewrite them by hand, or point the whole thing at a dbt target schema. The pitch is not "it understands your data". It's "the three things it cannot guess, you only have to say once." Compare that with pasting your schema into a general chat assistant, where you re-explain every session.
And for anything non-trivial, you get a readable query plan first — sources, fields, joins, filters, groupings, aggregation, in business terms with the raw SQL one click away — and you press Execute or Adjust. That is what makes a wrong assumption findable. It is also, honestly, worth less if you can't read SQL; showing a receipt in a language you don't speak isn't transparency.
When Vanna is the better choice
Often.
- You're 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.
- Nothing, including metadata, may leave your infrastructure. Self-hosting is the answer and no SaaS will match it.
- 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. Intellrise does not.
- 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 means none of that is anyone's decision but yours.
- You already have curated question–SQL pairs. That's real accuracy 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.
If you got here without a database
Some of you don't have a database at all and are wondering whether any of this applies. Short version: you don't need one — a Google Sheet, a CSV or an Excel file works. But be clear on the cost before you sign up, because we'd rather you hear it from us:
- Uploading files is a Pro feature. It is not on the free plan.
- Every new account starts with 14 days of Pro, with no card — nothing to enter, nothing to cancel. So your files are free to test here, not free to keep here. After 14 days you land on the permanent free tier: one database source plus Google Sheets, three dashboards.
- An uploaded file is a snapshot. We store the copy you send and analyse that, so when the underlying data changes you upload it again.
- There is a public demo at
intellrise.com/demo— a sample dataset, the questions verbatim, and the answers, including the ones where the model got it wrong — that needs no signup and no AI key.
How to actually decide
Don't decide from a comparison table, including this one. Run one question you already know the answer to — last March's revenue, last quarter's top ten customers, whatever you have a pivot table for — and see whether the number matches and whether you can tell why it matches. If it can't reproduce a figure you already hold, you've learned what you needed in ten minutes. That test works on Vanna, on Vanna Cloud, on us, and on whatever you try next.
Originally published at https://intellrise.com/guides/vanna-ai-alternative/. Every Vanna figure above was read first-hand from Vanna’s own sources on 30 August 2026 — the GitHub REST API, the raw README, and vanna.ai/pricing — not copied from another comparison article. Check them before you decide anything; they move.
Top comments (0)