Vanna text-to-SQL library archived with no explanation, leaving production users to migrate

What happened

The vanna-ai/vanna repository, a widely used open-source library for generating SQL from natural language, was archived by its owner on 29 March 2026. According to a post on dev.to by Ashish Sinha, the repository had accumulated roughly 23.8k stars and is now read-only, with no pinned explanation for the change. Sinha writes that he deliberately avoids speculating about the maintainers' motives, noting that many users got genuine value from the project for free.

What read-only means in practice

Nothing breaks on day one: an application pinned to a working Vanna version keeps running. What ends is everything around the code. An archived repository receives no dependency bumps, no fixes when the next database driver change lands, no security patches, and its issue tracker and pull requests are closed. That last point carries a hidden cost — the workaround that would normally surface in a comment thread never gets written.

Sinha puts the practical horizon at the next breaking change in a layer underneath: SQLAlchemy, a database driver, or an LLM SDK. His estimate is that this typically arrives in months, not years.

Vanna was five components, not one

The trap when searching for a replacement, the post argues, is that Vanna bundled several distinct jobs:

• a training store holding your DDL, documentation and example SQL
• retrieval, which picks the schema relevant to a given question
• prompt assembly
• the LLM call
• UI and chart helpers

No single maintained library covers all five. LangChain's SQL agent and LlamaIndex's NLSQLTableQueryEngine handle the middle three with different design opinions, while MCP-based toolboxes cover prompt assembly and the model call and leave the training store and retrieval to you, according to the post.

Retrieval is where the risk sits

The component Sinha singles out is retrieval, because it decides what the model is allowed to see and runs before the query executes — and therefore before row-level security, virtual private databases, or any other policy layer can act.

The failure mode he describes works like this: a retrieval layer that is not identity-aware hands the model a table the caller cannot read. The model writes perfectly valid SQL, the policy layer filters every row, and the agent reports that no orders exist for that customer. The result is not an access-denied error but a plausible sentence asserting something false — the reader cannot tell "you may not see this" apart from "this does not exist." Nothing logs an anomaly either, because every component did its job. He contrasts this with a GRANT, which produces a clean permission error, versus row-level security, which produces the misleading sentence.

A migration checklist

• Pin the Vanna version and its transitive dependencies now, before something shifts underneath.
• Write down which of the five pieces you actually use — most teams, per Sinha, rely on retrieval, prompt assembly and the LLM call and never touched the UI helpers.
• Export the training data. It is yours, portable, and the expensive part.
• Decide where identity enters: per request, before retrieval, not after execution.
• Explicitly test the empty-result case. Ask a restricted user something they should not be able to see and check what the agent tells them. Sinha calls this the ten-minute test nobody runs.

One disclosed alternative

Sinha discloses that he wrote schemagate, an Apache-2.0 project covering retrieval plus identity scoping only, and states plainly that it is not a Vanna replacement. It filters the catalog by caller identity before ranking, so a restricted table's name never enters the prompt, using BM25 plus a hashed embedder offline, with no API key and no model call. On a deliberately messy 127-object schema, he reports recall@6 of 47% with bare identifiers, 60% with table descriptions written by Gemini 2.5 Pro, and 80% with Sonnet — his takeaway being that anyone rebuilding retrieval should budget for the description pass, not just the embeddings.

Why it matters

An archived library that still runs today is not stable; it is waiting for the next breaking change in its dependencies. Vanna's disappearance without explanation puts production users on a clock, and the unbundling problem means there is no drop-in successor — teams must reassemble five separate capabilities from different tools. More broadly, the retrieval-before-policy failure mode applies to any text-to-SQL system, maintained or not: if the step that selects schema is not identity-aware, permission denials become confident wrong answers that no log will ever flag.