5. Installation: Self-Host in Minutes

git clone https://github.com/Canner/WrenAI.git
cd WrenAI
docker compose up --build -d
open http://localhost:3000

Configure your LLM in config.yaml:

language: English

llm:

  provider: ollama

  model: qwen2.5:14b

  base_url: http://localhost:11434

Restart the AI service:

docker compose up -d --force-recreate wren-ai-service

For detailed provider examples (OpenAI, Gemini, Bedrock, etc.), WrenAI ships configuration docs per provider.

6. Data Sources: 12+ and Growing

WrenAI supports a broad set of engines:

• PostgreSQL, MySQL, Microsoft SQL Server, Oracle
• BigQuery, Snowflake, Redshift, Databricks
• DuckDB, ClickHouse, Trino, Athena
• Apache Spark (and more via community votes)

7. Hands-On: From Question to SQL

You see the SQL. You can edit it. The model isn't a black box; the semantic layer is inspectable and version-controlled.

8. GenBI Insights and Charts

Beyond SQL, WrenAI produces AI-generated summaries alongside queries, turning raw results into actionable visuals. The GenBI feature converts query results into reports and charts. In the newer open-core, GenBI apps are agent-built, browser-side dashboards powered by wren-core-wasm, deployable to Vercel or Cloudflare Pages.

WrenAI also answers exploratory questions — "What data do I even have?" — which is genuinely useful when onboarding onto an unfamiliar warehouse.

9. Agent-Native and MCP

WrenAI exposes an MCP server via wren-engine, so agent workflows can call it. The framework SDKs (LangChain, Pydantic AI) let you attach a Wren project to agent frameworks. Skills like generate-mdl, onboarding, enrich-context, and genbi run on demand from the wren CLI, so AI coding agents can operate WrenAI safely and reproducibly.

This is the forward edge: not just a chat UI, but a component other agents can use to query governed data.

10. Honest Limitations

WrenAI is honest about its ceilings:

• SQL quality depends heavily on the LLM. The docs explicitly recommend the most powerful model available; weak models produce weaker, slower, or inaccurate SQL. With Ollama, a 14B-class local model is fine for simple schemas but will struggle on gnarly multi-join questions.
• Semantic layer setup is real work. MDL is what makes it accurate, and defining it takes effort — especially for messy legacy warehouses. The payoff is accuracy; the cost is upfront modeling.
• Classic is sunset. The earlier Docker-based chat-first product (Wren GenBI Classic) is on a legacy branch and gets no security fixes. Use the actively maintained open-core.
• Not a full BI replacement. It's excellent for ad-hoc, governed questioning; it's not Tableau for pixel-perfect dashboards (though GenBI apps are closing that gap).
• Retrieval can miss. If your MDL is thin, retrieval returns the wrong context and the SQL drifts.

11. What It Costs

WrenAI is open-core and free to self-host. Your costs:

• Your LLM bill — cloud models (OpenAI/Gemini/etc.) per token.
• $0 for inference if you run Ollama locally — but you pay in GPU/RAM and electricity.
• Your infra — Docker host, Postgres/Redis/Qdrant. A small VPS or a workstation handles it.
• Your time — modeling the MDL, the part that buys accuracy.

12. Where Your Data Goes

This is the privacy core. Your data stays in your database. WrenAI connects to it; the model (if Ollama) runs on your machine. The only thing that leaves your network is what you explicitly route to a cloud LLM — and if you pick Ollama, nothing leaves at all.

13. Troubleshooting

• SQL is wrong? Your MDL is too thin. Add relationships and calculated fields; the model grounds on those.
• Port 3000 busy? Change HOST_PORT in .env.
• Service won't start? Docker needs 8GB+ RAM recommended; check docker compose logs [service].
• Local model weak? Bump the Ollama model size (e.g., 14B → 32B) if you have VRAM; or use a cloud model for hard queries.
• Classic vs core confusion? Use the maintained open-core; the legacy/v1 branch is sunset and unmaintained.

14. Who Should Use It

Use WrenAI if: you're a data/product/business team that wants governed, plain-English database access; you need self-hosted BI without shipping schemas to a vendor; or you want a component other agents can query. It's especially strong paired with Ollama for fully private GenBI.

Skip it if: you need pixel-perfect executive dashboards (use a dedicated BI tool), or you can't invest in modeling the semantic layer (a raw "LLM + schema" approach will disappoint).

15. FAQ

Is WrenAI open source? The core is open (MDL, Rust engine, CLI, wren-core-wasm, SDKs). A hosted commercial tier also exists.

Can it run fully locally? Yes — Ollama for the model + a local DuckDB/Postgres for data = no data leaves your network.

Which databases? 12+, including PostgreSQL, MySQL, BigQuery, Snowflake, DuckDB, ClickHouse, Trino, SQL Server, Databricks, Redshift, Oracle, Athena, Spark.

Why not just prompt an LLM with my schema? Because business meaning isn't in the schema. MDL encodes it; retrieval grounds the SQL. Accuracy is the whole point.

How is it different from Open WebUI? Open WebUI is a chat frontend for models. WrenAI is a BI agent with a semantic layer for databases. Different job — see the Open WebUI deep-dive for the chat side.

16. Building the MDL: A Concrete Example

The semantic layer is where accuracy is won or lost. Here's a small but real MDL snippet for a SaaS schema:

models:
  - name: customers
    columns:
      - name: id
      - name: created_at
      - name: last_login_at
  - name: orders
    columns:
      - name: id
      - name: customer_id
      - name: amount
      - name: created_at
relationships:
  - name: orders_customer
    from: orders.customer_id
    to: customers.id
calculated_fields:
  - name: active_customer
    model: customers
    formula: "last_login_at >= now() - interval '30 days'"
views:
  - name: monthly_revenue
    model: orders
    measures:
      - name: total
        aggregation: sum
        column: amount
    dimensions:
      - name: month
        column: created_at
        grain: month

Now "top customers by revenue last quarter" resolves to a clean join on orders.customer_id → customers.id, grouped by quarter, filtered to created_at in range. "Active customers" uses the defined 30-day rule — not the model's guess. The MDL is the difference between "plausible SQL" and "correct SQL," and it's reviewable and version-controlled like code.

17. WrenAI vs Naive Text-to-SQL

A naive approach: dump the DDL into a prompt and ask for SQL. Failure modes:

• Invented columns — the model guesses a revenue column that doesn't exist.
• Wrong joins — links orders.user_id when it's customer_id.
• No business logic — "active" becomes status = 'active' when your rule is time-based.
• No validation — the SQL runs and errors, or worse, runs and lies.

18. Privacy Deep-Dive: What Actually Leaves Your Network

People hear "AI queries my database" and assume the whole warehouse ships to a model. With WrenAI + Ollama, here's the real data flow:

If you instead point WrenAI at a cloud LLM, step 2 sends that retrieved context to the provider. That's narrower than "ship the warehouse to a vendor BI cloud," but it's still exposure — so for the strictest setups (HR, finance), use Ollama and keep the model local. The architecture makes "fully private GenBI" a configuration choice, not a rewrite.

19. Running WrenAI in Production

For a real deployment:

• Model choice is the lever. Use the strongest model you can for the SQL step; weak models produce weak SQL. A 14B local model is fine for simple schemas; for gnarly multi-join questions, use a cloud model or a 32B+ local one.
• Put it behind auth. The Docker stack exposes :3000; put it behind a reverse proxy with SSO if multiple analysts use it.
• Size the host. Postgres/Redis/Qdrant + the AI service want 8 GB+ RAM. A small VPS or a workstation handles a team.
• Version the MDL. Treat modeling_definition.yaml (or the MDL files) like code — review changes, because a bad definition silently degrades every query.
• Cache embeddings. Qdrant holds context embeddings; size it for your schema breadth.

20. Limitations, Honestly

The line between "magic" and "disappointing" is the MDL:

• No MDL, no accuracy. Point WrenAI at a raw schema with no definitions and you get plausible-but-wrong SQL — the exact failure it exists to prevent. The fix is modeling, which is work.
• Model-bound. SQL quality tracks your LLM. A free local 7B will frustrate you on anything complex.
• Not pixel-perfect BI. It's excellent for governed ad-hoc questions; it's not Tableau for board decks (GenBI apps are closing this, but slowly).
• Classic is sunset. Use the maintained open-core; the legacy chat product is unmaintained.
• Retrieval can miss. Thin MDL → wrong context retrieved → drift. You must curate.

22. A Guided MDL Session

Let's model a tiny business — a coffee subscription — interactively:

1. Connect orders (id, customer_id, amount, created_at) and customers (id, email, city, signup_date).
2. Define relationship: orders.customer_id → customers.id. Now "revenue per customer" joins correctly.
3. Add a calculated field: ltv = sum(amount) grouped by customer_id. "What's my top customer's LTV?" now resolves.
4. Add a view: monthly_recurring = sum(amount) where created_at in last 30 days, by city.
5. Ask: "Which city has the highest LTV?" → WrenAI retrieves the ltv definition and the relationship, generates SQL against them, returns the answer with the query shown.

23. WrenAI vs Traditional BI Tools

Where does WrenAI sit versus Metabase or Looker?

• Metabase/Looker: you (or an analyst) write the query or define the model; business users click dashboards. Great for known questions; poor for "ask something nobody charted."
• WrenAI: you ask in English; it generates the SQL from the semantic layer. Great for ad-hoc, governed exploration; less polished for pixel-perfect executive dashboards (today).

25. WrenAI for Non-Technical Analysts

The pitch isn't only for engineers. A business analyst who can't write SQL can:

1. Open the Wren UI, connect the warehouse (IT does this once).
2. Ask "which product line grew fastest last quarter?" in plain English.
3. Read the answer — and the SQL underneath, shown for trust.
4. Click "chart" to visualize, or "export" to a spreadsheet.