text2sql-assistant: Nexus AI Query: The Local-First Text-to-SQL Copilot That Keeps Your Schema at Home
A FastAPI, React, and Ollama stack that turns natural language into PostgreSQL queries without sending your data to a cloud model.
- Nexus AI Query argues that the real product value of text-to-SQL is not convenience alone, but keeping schema, prompts, and execution inside the same local environment.
- The repo is intentionally thin in the backend, which makes the pipeline easy to follow but also exposes the security gap between a prototype and a production-safe tool.
- The frontend matters because it frames the app like an operations console, which makes a simple query box feel like part of a serious system.
- Seeded demo data and a compact local model turn the project into a fast, self-contained proof of concept rather than a sprawling platform.
Why this project exists
The problem Nexus AI Query solves is not SQL. It is trust. Teams want natural-language access to their data, but many do not want to hand schemas and query intent to a cloud model just to answer a question.
That makes this repo interesting in a very specific way. It is a privacy-first answer to a corporate AI dilemma, and it does not try to be clever about it. The model is local, the database is local, and the whole pipeline stays small enough to understand at a glance.
A tiny model, a local database, and a very short trust chain
The architecture is almost blunt in its simplicity. A user asks a question, the backend injects schema context into the prompt, Ollama generates SQL, the app strips markdown fences, and PostgreSQL executes the result locally.
That is the key idea: the model is not a distant API dependency. It sits beside the database workflow, which reduces the number of places where sensitive context can leak.
How the query pipeline actually works
The most revealing line in `backend/main.py` is also the most ordinary one. The app strips away markdown wrappers before execution, because LLMs like to answer in fenced code blocks and PostgreSQL does not care about that formatting.
sql_query = raw_ai_response.replace("```sql", "").replace("```, "").strip()That tiny cleanup step tells you a lot about the repo’s philosophy. It is not building a grand abstraction layer. It is building the shortest useful path from prompt to query.
The other notable choice is the hardcoded schema context. Instead of asking the model to discover the database from scratch, the backend supplies table names and column types up front. That improves usefulness, but it also means the system depends on careful prompt construction rather than deeper reasoning.
The frontend is doing more than looking good
The React app is not a thin wrapper around a form. It presents the system like an operations console, with status indicators, a live clock, and a polished glassmorphism layout that makes the tool feel monitored rather than casual.
That matters because interface shape changes user trust. A dashboard with visual structure suggests an internal tool that belongs in a real workflow, not a novelty demo.
The UI also gives the backend story a better frame. Instead of emphasizing chat, it emphasizes control. That makes the product feel less like a chatbot and more like a query instrument.
The fastest path is not the safest path
| Dimension | Nexus AI Query | Cloud text-to-SQL copilot | Manual SQL dashboard |
|---|---|---|---|
| Privacy | Keeps schema and execution local | Usually sends context to a remote model | Keeps data local, but requires SQL fluency |
| Speed to answer | Fast for simple questions | Fast, but depends on network and service | Fast only for experienced users |
| Security posture | Prototype-level, with direct SQL execution | Depends on vendor controls and policy | Strong if users are trusted, weak if they are not |
| Setup | Small stack, simple mental model | Often easier to start, harder to govern | Familiar, but steeper for non-SQL users |
| Best fit | Local, constrained, privacy-sensitive workflows | Broad enterprise adoption with external AI accepted | Analysts and engineers who already write SQL |
The comparison makes the trade-off obvious. Nexus AI Query is not the most capable option, and that is not the point. It is the most self-contained one.
That self-containment comes with a sharp edge. The backend executes AI-generated SQL directly, which is elegant for a prototype but risky in production. Prompt injection, destructive queries, and accidental misuse are all real concerns once the system leaves a trusted demo environment.
Seed data, instant demo, and prototype maturity
The `seed.py` approach is a quiet strength. By generating realistic employee records instead of shipping a static dump, the repo makes setup feel immediate and productized.
That is a good sign in a prototype. It means the author is thinking about onboarding, not just code paths. A fresh clone can become a live demo quickly, which is exactly what a local-first proof of concept should do.
The maturity level is still early. The stack is clean, the flow is understandable, and the UI is polished, but the security story is not hardened. That tension is the real story here: strong UX and honest constraints, not enterprise completeness.
What it looks like next to cloud copilots
| Approach | Privacy | Operational overhead | Model strength | Risk profile |
|---|---|---|---|---|
| Nexus AI Query | High, because it stays local | Low | Good enough for constrained SQL tasks | Direct SQL execution needs guardrails |
| Cloud copilots | Lower, because context leaves the machine | Medium to high | Typically stronger general reasoning | Governance and vendor dependency |
| Manual SQL tools | High, because no AI layer is involved | Low to medium | N/A | Relies on human expertise |
The project’s advantage is not raw intelligence. It is fit. When the main constraint is data locality, a small local model plus PostgreSQL is a strong answer.
Nexus AI Query is best read as a blueprint. It shows how far you can get with a narrow trust chain, a thin backend, and a UI that makes the result feel operational instead of experimental.