Wren AI vs DB-GPT vs Vanna vs Dataherald: the generator was never the product

At a glance

Four projects that were the obvious shortlist eighteen months ago, and are no longer the same kind of thing as each other.

Read that chart the way a maintainer would. Vanna's 23.8k is a true measurement of how badly people wanted a two-line path from a question to a query in 2024 — and it tells you nothing about whether anyone will merge your patch in 2026. Dataherald's 262 forks against 3.6k stars is the signature of a project people bookmarked rather than deployed. If your shortlist came from a star-sorted list, it is two years stale.

What actually happened to the two that stopped

Neither project failed in the way open-source projects usually fail. Vanna was archived deliberately, with a finished 2.0 in the README describing a complete rewrite around user-aware agents, lifecycle hooks, LLM middlewares, conversation storage and observability — and the ongoing product is Vanna Cloud, a paid hosted offering. That is a company deciding the open library was distribution and the managed service is the business. It is a legitimate decision and it is fatal to you if you were treating the repo as infrastructure: the code is MIT and yours to fork, but forks of a 972-commit codebase are a staffing commitment, not a licence question.

Dataherald is the quieter shape. Apache-2.0, four services, an architecture people still cite approvingly in comparison posts — and a main branch whose newest commit is a documentation change from July 2024. Twenty-six months is not a lull; it is the entire lifespan of the tool-calling and structured-output APIs that any current NL-to-SQL system would be built on. Anything you deploy from it, you are maintaining against model APIs it has never seen.

The useful question is not which of them was better engineered. It is what the two survivors have that these two did not.

The generator got commoditised; the meaning did not

In 2023, generating syntactically valid SQL against an unfamiliar schema was hard, and a project that did it well had a product. That capability is now a baseline feature of every frontier model and most open-weight ones; the residual errors are almost never syntax. They are semantic: the query joined the right tables and returned a number that means something other than what was asked for, because orders.total includes cancellations, because "active customer" has a definition that lives in a dbt model nobody exported, because the finance team's revenue excludes intercompany and the sales team's does not.

Wren AI states this as its architecture. Business meaning, approved definitions and proven examples are captured in a Modeling Definition Language manifest — models, columns, relationships, views, cubes, metrics — held in the repository, version-controlled, reviewed. The engine underneath is Rust on Apache DataFusion, and the MDL is a JSON schema, which matters more than it sounds: your semantic layer is a portable document rather than an internal state you would have to reverse-engineer to leave.

Vanna's design was the exact opposite, and deliberately so: no semantic layer, no bundled opinion, a training-and-retrieval loop where you feed it DDL, documentation and question–SQL pairs and it retrieves the relevant ones at query time. That is a genuinely lower-friction start, and it is why it got 23.8k stars. It is also an accumulated corpus rather than a document — you cannot diff it, a reviewer cannot approve it, and when a definition changes you are hunting for the stale pairs that still teach the old one. The knowledge was real, but it was never an artefact anyone owned.

DB-GPT sits between them and answers a wider question. It is a data-agent framework — SQL generation, Python analysis, RAG, report generation, multi-model serving, plus AWEL for orchestrating flows and a separate DB-GPT-Hub line of work on fine-tuning models for Text2SQL. Meaning lives partly in AWEL flow definitions and partly in retrieved knowledge, which is more reviewable than a training corpus and less canonical than a manifest. If you want one runtime that also writes the Python and the report, this is the only one of the four still offering it.

The fine print that actually decides adoption

Three specifics worth knowing before a licence review, none of which appear in the usual comparison tables:

• Wren AI's licence is multi-licensed by path, not by repo. core/, sdk/, skills/, examples/ and the root files are Apache-2.0; docs/ is CC BY 4.0. There is also a pre-emptive LICENSE-AGPL-3.0 file in the tree for modules the project says it may add later — no path maps to it today, but a legal reviewer who greps for "AGPL" will find it and stop, so get ahead of that conversation rather than discovering it in week three.
• The repository consolidation is recent. Canner/wren-engine was merged into Canner/WrenAI under core/ in May 2026 and the old repo frozen. Any tutorial, Docker compose file or issue thread older than that points at a layout that no longer exists.
• DB-GPT's breadth is also its integration surface. Multi-model serving, RAG, agents, AWEL and fine-tuning in one project means more moving parts to pin, and its recent commit log is exactly what you would expect from that — connector fixes, flow-compatibility fixes, provider additions. That is a healthy signal about maintenance and an honest signal about surface area.

And the point that applies to all four: none of them supplies your semantic layer. Wren AI gives you a good format and a review workflow for one; DB-GPT gives you places to put it; the other two gave you a way to accumulate it implicitly. The authoring is the work, it takes a data team weeks, and it is the only part of this stack that will still be worth something after two more model generations. Teams that skipped it got a demo that answered five questions beautifully and then produced a confidently wrong number for the CFO — which is the failure mode data and analytics agents is organised around.

When to pick which

The column that should be doing the most work in your evaluation is the last one. A single warehouse and a stable set of questions is answered by views and a dashboard, at a fraction of the operating cost and with none of the semantic ambiguity. Text-to-SQL earns its complexity when the question space is genuinely open and the schema is genuinely large — and it earns nothing at all until somebody has written down what the columns mean.

Further reading

On this wiki:

• Data & Analytics Agents — schema grounding, read-only execution, and scoring abstention above confident error.
• Query Understanding for RAG — the disambiguation step that decides whether the retrieval was ever going to work.
• Structured Outputs — why constrained generation moved the hard part away from syntax.
• Tool Design Principles — what a good "query the warehouse" tool looks like from the model's side.
• Hallucination & Grounding — the confidently wrong number, and why grounding makes it cheap to catch.

Project sources:

• Canner/WrenAI
• eosphoros-ai/DB-GPT
• vanna-ai/vanna (archived)
• Dataherald/dataherald