Alternatives to Vanna for text-to-SQL agents (2026)

What does the Vanna archive mean?

When we checked the repository in October 2026, GitHub showed it as a public archive: read-only, with 227 open issues and 62 open pull requests that nobody can act on, an MIT license, and about 23,800 stars. Because the license is MIT, anyone is free to fork it and keep going.

What the archive does not tell you is that the company has disappeared. An independent write-up published at the end of August 2026 reported that Vanna's website and paid hosted plans were still live. We haven't verified that ourselves, so check Vanna's own site for its current status and pricing.

In practice, an archived project doesn't stop working. It stops adapting. Database drivers release new versions, model providers change their SDKs and retire older models, and Python versions move on. With a maintained project, someone else deals with that. With an archived one, it becomes your job. And because a text-to-SQL agent's answers depend on a model you don't control, the code you pinned can quietly start answering differently when the model changes, with no error to warn you.

What does Vanna offer, so you know what to replace?

According to its README, Vanna 2.0 is a Python framework with user-aware agents: row-level security, audit logs and per-user rate limits. It works with many language models and databases, and it includes a ready-made chat component for web pages. Any alternative will cover some of these and not others, so start by deciding which ones you actually used.

Vanna alternatives at a glance

What are the Vanna alternatives in more detail?

1. Keep Vanna and own a fork

If Vanna already works for you, this is often the cheapest correct answer. Pin your versions, fork the repository into your own organization, and plan time for dependency updates. The code is unchanged, so the effort goes into everything around it: drivers, SDKs, Python versions and, less visibly, how your model behaves over time. Re-run your test questions whenever your model or its version changes (see our guide to testing a text-to-SQL agent: /blog/how-to-test-a-text-to-sql-agent).

This suits you if you want to read and change every line, run local models, or keep everything inside your own infrastructure.

2. Vanna's hosted product

This suits you if you liked how Vanna behaves and didn't need to own the code. You're still on the same team's technology, but as a service. Compare the current plans, daily question limits and terms on their site before deciding, and confirm where your data and your model key go.

3. Wren AI

Wren AI takes a different approach. Instead of retrieving examples and documentation to guide the model, you define your business terms (revenue, churn, active customer) in a semantic layer first, and SQL is generated from those definitions. A September 2026 comparison by Querio, a vendor in the same space, described it as still actively maintained as open source, and listed Postgres among the databases it supports.

That comparison also noted the main cost: someone has to build and maintain the semantic model. The same piece described the typical failure modes as different. Wren AI fails when a concept isn't defined in the model, while Vanna fails when its training material goes stale. It's a useful way to think about both.

This suits you if you need consistent metrics for analysts and are willing to do the modeling work.

4. LangChain or LangGraph SQL agents

These are building blocks, not a finished product. LangChain's own documentation says that running model-generated SQL carries inherent risks, and tells you to scope database permissions as narrowly as possible. Its SQL agent tutorial describes its database tools as minimal wrappers for demonstration only, and recommends adding your own validation before executing model-generated SQL.

That is an honest description of the trade-off. You get flexibility, and you also own the read-only role, the query validation, the logging and the tests.

This suits you if you have engineering time and want the agent logic in your own codebase.

5. Database MCP servers

MCP servers let an AI client such as an IDE or an assistant talk to your database with little setup. Supabase's MCP server, for example, has a read-only option that runs queries as a read-only Postgres user, and can be scoped to one project. Supabase's documentation also states that its MCP server is designed for development and testing, and names prompt injection as the main risk.

That makes MCP servers a good way to explore your data while building, and a poor choice as the access layer for a production agent that serves other people.

6. A managed layer such as Claix

Claix is a hosted service that sits between your agent and your database. You connect Postgres or Supabase with a read-only role, choose the tables and columns each agent can use, and write a short guide with your business rules. Each agent gets its own endpoint, over REST, MCP or A2A, and returns validated results or typed answers. Every request is traced.

The difference from Vanna is where the work lives. Vanna is a framework you host, extend and maintain. Claix is a service you call, so there is no code to host and nothing to patch.

Claix is not the better choice in every case:

• You need per-end-user row filtering inside the tool. Vanna 2.0 documents user-aware permissions. Claix scopes access per agent, so per-person rules stay in your database or your application.
• You must self-host everything. Claix is a managed service.
• You want charts and an analyst interface. Claix returns data and answers to your agent, and doesn't ship a dashboard.
• You use a database other than Postgres or Supabase. Those are what Claix supports today.
• You need governed business metrics across analyst teams. A semantic layer such as Wren AI is built for that.

How should you choose a Vanna alternative?

Ask yourself four questions:

• Who will use the answers? An agent or an application points to a service or a framework. Analysts using a chat interface point to Wren AI or Vanna's hosted product.
• Do you want to host and maintain code? If yes, a fork, Wren AI or a LangChain agent. If no, a hosted service.
• Do you need business metrics defined centrally? If yes, a semantic layer.
• Does the agent serve other people, or only you? For other people, read-only roles, query validation and logging stop being optional. Development tools aren't built for that.

What should you carry over from Vanna?

If you move, don't start from zero. Three things you've already built are valuable anywhere:

• Your schema descriptions and business definitions. Good documentation helps every approach (see /blog/how-to-document-your-database-for-ai-agents).
• Your question and SQL examples. They become your test set, which lets you compare the new option with the old one on your own questions.
• Your permission rules. Write down who can see what, and rebuild it as database permissions, not as prompt instructions.

What should you check in any replacement?

• It is actively maintained, or you accept that you'll maintain it.
• It connects with a read-only, narrowly scoped role.
• Queries are validated before they run.
• There are limits on time, rows and cost.
• Every request is logged.
• You can test it with your own questions, including attack cases.
• You know where your data and your model key go.
• You can leave: your descriptions and examples are yours to export.

Sources

Claims about other products in this article come from their own documentation or from independent write-ups checked around October 2026: the Vanna GitHub archive status and README, an August 2026 independent note on Vanna's hosted plans, Querio's September 2026 Wren AI comparison, LangChain SQL agent documentation, and Supabase MCP documentation. Re-check those sources before you decide—this category moves fast.