Wren AI

Last reviewed Aug 26, 2026 · 826 words

Text-to-SQL without a semantic layer is a guess dressed as an answer. Wren AI's whole value is the modeling step that most people skip: you describe tables, relationships and business terms once, and the model generates SQL against that description rather than against raw column names. Do the modeling and "revenue by region last quarter" returns the same number your analyst would produce. Skip it and you get plausible SQL joined on the wrong key, which is worse than no answer because it looks right.

Modeling is the work; questions are the reward

After connecting a database, Wren AI imports the schema and asks you to build models: which columns matter, how tables relate, what "customer" or "active" means as a calculated field. It stores this in a modeling definition, and the engine uses it to plan every query. Budget the first 2 hours here for a 20-table schema. Name relationships explicitly, define the 5 to 10 metrics people actually ask about, and add descriptions in plain language, because those descriptions are what the language model reads. Afterwards the chat interface does what the marketing shows: a question, generated SQL you can inspect, a result table, and a chart. The generated SQL is always visible, and you should read it for the first 20 questions until trust is earned.

Half a dozen containers, and 4 GB is a real minimum

The launcher pulls a compose stack: the UI, the AI service, the query engine, a data-source connector service, and a Qdrant vector store for the semantic index, with the UI on port 3000 by default. The catalogue's 4 GB floor is accurate; with Postgres and a couple of other services on the same host, plan on 8 GB. Everything is state-light except the UI's own database and the Qdrant collection, both of which you should back up before an upgrade.

curl -L https://getwren.ai/launcher -o wren-launcher
chmod +x wren-launcher
./wren-launcher

The launcher walks through the LLM configuration and writes the compose and .env files, which you can then edit directly for a persistent server install.

Bring an API key, or bring Ollama

Wren AI needs a language model and an embedding model. The default path is a hosted key, and that is a con for a self-hoster: the schema descriptions and questions leave your network, even though row data does not. Point it at Ollama instead and the entire loop stays local. The honest trade-off is quality; text-to-SQL is one of the tasks where a strong hosted model still beats a 7B local model by a wide margin on multi-join questions. A pragmatic split is a capable local model of 14B or larger on a GPU box for daily use, with a hosted key reserved for a non-sensitive schema. The config file selects the provider, and switching takes a restart.

Give it a read-only user, no exceptions

Wren AI generates and runs SQL. Create a dedicated database role with SELECT on the schemas it needs and nothing else, and connect with that. This is the one setup rule I would not bend for convenience, because the failure mode is a generated DELETE running against production. On Postgres it is 3 statements:

CREATE ROLE wren_ro LOGIN PASSWORD 'a-long-random-value';
GRANT USAGE ON SCHEMA public TO wren_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO wren_ro;

If the data lives in a busy production database, point Wren AI at a read replica or a nightly copy; the Postgres for everything piece covers why a replica is cheap insurance.

Where it stands next to Superset

Superset is a dashboarding tool with an optional SQL editor; Wren AI is a question-answering tool with charts as a by-product. They are complementary. Superset wins for a fixed set of dashboards viewed daily by people who never write a query; Wren AI wins for the long tail of one-off questions that used to become tickets for whoever knows SQL. The licence matters if you plan to expose it: AGPL-3.0 is fine for internal use and for hosting it for your own team, but if you modify it and offer it to others as a service, the open-source licence rules apply.

What I'd do

Install it against a read replica, spend the first afternoon on the semantic model rather than on questions, and run the model through Ollama unless the schema contains nothing sensitive. Give 3 non-technical colleagues access and watch which questions fail; each failure is a missing description or relationship in the model, and fixing 10 of those turns it from a demo into a tool. Keep Superset for the dashboards. Wren AI replaces the "can you pull a quick number" message, not the weekly report.