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. What read-only actually means 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. Vanna was five things, not one This is the part that catches people out when they start looking for a replacement. Unbundled, it did roughly: A training store - your DDL, docs and example SQL, embedded Retrieval - pick the relevant schema for this question Prompt assembly The LLM call UI and chart helpers 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. The piece that carries the risk is #2 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. A migration checklist that isn't just "pick a framework" Pin your Vanna version and your transitive deps now, before something moves under you Write down which of the five pieces you actually use. Most teams use 2, 3 and 4 and never touched 5 Export your training data. It's yours, it's the expensive part, and it's portable Decide where identity enters. Per-request, before retrieval - not after execution Test the empty-result case explicitly. Ask something a restricted user shouldn't see, and check what your agent tells them That last one takes ten minutes and is the one nobody runs. Disclosure 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/ Apache-2.0: 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.