// the find
getnao/nao
👾 nao is an open source analytics agent. (1) Create context with nao-core cli, (2) deploy nao chat interface for everyone
nao is a text-to-SQL analytics agent framework: data teams build a file-system context (schemas, metadata, rules, docs) with a Python CLI, then deploy a TypeScript chat UI that lets business users ask natural language questions against their warehouse. It targets data engineering teams who want to give non-technical stakeholders self-serve analytics without SaaS pricing. BigQuery, Snowflake, Databricks, and PostgreSQL are supported out of the box.
The context-engineering separation is the right call — data teams control exactly what the agent knows (schemas, RULES.md, sample queries) independently of the chat deployment, which means you can version and test the context before it hits users. The built-in evaluation framework (`nao test` with YAML question/expected-SQL pairs) is something most text-to-SQL projects skip entirely and then regret; having it as a first-class command matters. The stack is coherent — Fastify + tRPC + Drizzle on the backend, Tanstack Query + shadcn on the frontend, Drizzle migrations for both SQLite (dev) and Postgres (prod) — nothing fighting itself. Docker support with volume-mounted project directories makes self-hosted deployment straightforward.
The toolchain is split across two runtimes: Python for `nao-core` (context building) and TypeScript for the server, plus there's a `fastapi/main.py` lurking in the backend directory suggesting a third Python server component — you'll need to manage all of them. The schema has churned through 48 migrations already, which is a lot of upgrade surface for self-hosters who skip versions. There's no visible row-level security model: if multiple teams share a nao deployment, there's nothing in the README or directory tree indicating that user A can be prevented from querying user B's data — a real problem in multi-tenant enterprise deployments. At 1,262 stars it's early-stage, and the docs site is external, so you're likely to hit underdocumented edge cases when your warehouse schema is messier than the happy-path examples.