Generated SQL is shown before it runs, and even the convenience tool that does the whole decision loop locally still stops for approval. Schema memory keeps metadata and never rows, and the model runs on your own Ollama instance — which is the point of the design: the credentials and the data both stay where they are.
A Python CLI and MCP server for read-oriented database work. It discovers the schema, remembers it, generates SQL, shows that SQL for approval, runs the approved statement and summarises the result — with the model call going to a local Ollama instance rather than a hosted API.
- Schema discovered and stored as a local snapshot at `.db-insight/schema_memory.json`, so later questions do not rediscover the same structure — `discover_schema`, `refresh_schema_memory`, `schema_memory_status`, `catalog_overview`, `inspect_table`
- SQL generated for a question, explained, and executed only after approval — `generate_safe_sql`, `explain_sql`, `run_approved_sql`
- The whole loop in one call when you want it, still requiring explicit approval before execution — `ask_database`, `plan_tool_calls`
- Schema memory that holds metadata only, never table rows
A connection string in `DATABASE_URL` for Postgres or SQLite, plus `DB_INSIGHT_MODEL` and `DB_INSIGHT_OLLAMA_URL` for the local model. Install into a venv with `pip install -e ".[dev]"`, or run the published image `ghcr.io/enclavex-labs/db-insight:latest` and `ollama pull gemma3:latest` on the host. For team use, `db-insight mcp --transport streamable-http` with `DB_INSIGHT_MCP_HOST` and `DB_INSIGHT_MCP_PORT` serves at `/mcp` — put it behind your own auth, VPN or private network. The project's stated positioning is a read-only replica, an analytics database or staging, not production.
One command plus a key — docker pull ghcr.io/enclavex-labs/db-insight:latest, then supply credentials