Vanna is archived. What that means if you have it in production.

The vanna-ai/vanna repository, a 23.8k-star text-to-SQL library, was archived by its owner on 29 March 2026, leaving production users without dependency updates, security patches, or issue support. Developer Ashish Sinha warned that the practical risk horizon is the next breaking change in an underlying dependency such as sqlalchemy or an LLM SDK, and that rebuilding Vanna's retrieval layer requires identity-aware filtering to avoid agents returning confident but wrong answers under row-level security. Sinha released schemagate, an Apache-2.0 library covering retrieval and identity scoping, reporting recall@6 of 47% with bare identifiers, 60% with Gemini 2.5 Pro-written table descriptions, and 80% with Sonnet on a 127-object schema.

The vanna-ai/vanna repository was archived by its owner on 29 March 2026. 23.8k stars, read-only, no pinned explanation that I could find. I'm not going to speculate about why - that's the maintainers' business, and a lot of people got real value out of it for free. What I do want to write down is what archiving actually costs you if it's in your stack, because "it still works" is true right up until it isn't. Your pinned version keeps working. Nothing breaks today. What stops is everything around it: no dependency bumps, no fixes for the driver change that lands next quarter, no security patches, and issues and pull requests are closed - so the workaround you'd normally find in a comment thread never gets written. The practical horizon is the next breaking change in something underneath it. sqlalchemy, your DB driver, an LLM SDK. That's usually months, not years. This is the part that catches people out when they start looking for a replacement. Unbundled, it did roughly: There is no single library that is "Vanna but maintained", because those five pieces live in different places now. LangChain's SQL agent and LlamaIndex's NLSQLTableQueryEngine cover 2-4 with different opinions. MCP-based toolboxes cover 3-4 and hand you 1-2. Nobody hands you all five in one import. When you rebuild retrieval, you are deciding what the model is allowed to see. That step runs before the query executes - which means it runs before row-level security, VPD, or any policy layer can act. If your replacement isn't identity-aware, here's the failure: the model is handed a table this caller can't read. It writes perfectly correct SQL. The policy layer filters every row. The agent reports "there are no orders for that customer." That is not an access-denied message. It's a wrong answer in a confident tone, and the person reading it cannot tell the difference between "you may not see this" and "this does not exist." Worse, nothing logs an anomaly, because nothing went wrong - every component did its job. With GRANT you'd get a clean permission error. With RLS you get a plausible sentence. If you're carrying Vanna's retrieval forward or replacing it, that asymmetry is the thing to design against. That last one takes ten minutes and is the one nobody runs. I wrote a library called schemagate that covers piece 2 only - retrieval plus identity scoping. It is not a Vanna replacement and I'd rather say that plainly than have someone find out after migrating. It filters the catalog by caller identity before ranking, so a restricted table's name never enters the prompt; ranking is BM25 plus a hashed embedder, offline, no API key and no model call. On a deliberately messy 127-object schema, recall@6 was 47% with bare identifiers, 60% with Gemini 2.5 Pro writing table descriptions, 80% with Sonnet - so if you're rebuilding retrieval, budget for the description pass, not just the embeddings. That's the part I'd have wanted to know before starting. Demo runs in your browser, no signup and no database: https://ashishsinha1602.github.io/schemagate/ https://ashishsinha1602.github.io/schemagate/ Apache-2.0: https://github.com/ashishsinha1602/schemagate https://github.com/ashishsinha1602/schemagate If you're mid-migration off Vanna I'm genuinely interested in what you hit - the retrieval half is the part I've spent the most time in.