Jason Baddley logojb@baddley ~ $

// db-ai

Talk to your database in plain English.

DB AI is a desktop database client that pairs a modern SQL workbench with an AI assistant grounded in your live PostgreSQL schema — so you can explore a database by describing what you want instead of remembering exact syntax.

Designed & built solo — spec to shippedSource in a private repo

// the idea

The best of the big SQL clients, distilled around AI

Tools like DBeaver, TablePlus, DataGrip, and Chat2DB are each excellent, but sprawling. DB AI started from a written product spec that asked a sharper question: which capabilities actually matter day-to-day, and what changes when an AI assistant is a first-class part of the workflow rather than a bolt-on?

The answer is a focused, AI-first client. An LLM is grounded in your live schema and turns plain-English questions into SQL you can read and run — but every guardrail assumes it will eventually be pointed at a production database. Nothing runs on its own, writes are gated, and your credentials never leave your machine.

the differentiator

An AI assistant that knows your schema

The LLM never guesses in the dark. It is grounded in the live database — tables, columns, and relationships — so its SQL fits the schema in front of you.

Natural language → SQL
Describe what you want — “list all users with their order counts from last month” — and get runnable SQL you can inspect before executing. Nothing runs automatically.
Bring your own model
Choose Anthropic, OpenAI, or Auto (Anthropic first). Model IDs are overridable, and requests use whichever provider key you have configured.
Fix with AI
When a query errors, send the SQL and the exact error back to the model and get a corrected version in place — no copy-pasting stack traces around.
It learns from mistakes
Every SQL error is recorded locally and fed back into future generations so the model stops repeating the same mistakes. Accepted “Fix with AI” corrections become the strongest lessons.

trust layer

Built to be pointed at production

AI-generated SQL against a real database is only useful if it's safe. Guardrails are per-connection and explicit — never inferred.

Read-only safe mode
Flag a connection as safe and every write is blocked. Overriding requires typing ALLOW WRITES, and the override lasts only for the session.
Honest environment labels
dev / stage / prod badges come from the saved profile you set — not guessed from a hostname — so a “prod” badge always means you called it prod.
Destructive-query confirmation
DELETE, UPDATE, DROP, and TRUNCATE prompt for confirmation before they run, so a stray statement can't quietly reshape a table.
Timeouts & row caps
Per-connection statement timeouts and a configurable max-row cap keep a heavy query from hanging the app or pulling millions of rows.

the workbench

A real SQL editor, not a toy box

Everything you expect from a modern SQL client, focused on the PostgreSQL workflow.

Tabs & run modes
Multiple saved-query tabs, and run the selection, the current statement, or the whole script — whatever fits the moment.
EXPLAIN & ANALYZE
Plan a query with EXPLAIN (FORMAT JSON) without executing it, or run EXPLAIN ANALYZE for real timings, with the plan available as downloadable JSON.
Named parameters
Placeholders like :organization_id are filled in a params panel and substituted on Run/Explain/Analyze — while PostgreSQL ::type casts are left untouched.
Transactions & cancel
Wrap a multi-statement script in BEGIN … COMMIT with automatic rollback on failure, and cancel a long-running query mid-flight.

data operations

Browse, edit, and export

A full data grid for exploring and changing rows without hand-writing every statement.

Filter, sort & search
Apply a WHERE clause, order by any column, and search within the current page of results to find the row you're after.
Safe inline editing
Insert, edit, and delete rows behind an explicit Edit-mode toggle, with values validated by Zod schemas before anything is written.
Paginated for scale
First/prev/next/last navigation with 50–1000 rows per page and a live total count, so large tables stay responsive.
Export three ways
Download results as CSV or JSON, or generate INSERT statements from the browse grid to move data between databases.

schema & metadata

Understand the database, not just the rows

Navigate structure and relationships straight from PostgreSQL's own metadata.

Filterable table tree
A searchable tree of schemas and tables in the sidebar gets you to the object you need fast.
DDL viewer
Generate and copy CREATE TABLE DDL for any table to reuse in migrations or share with a teammate.
ER-lite foreign keys
See foreign keys database-wide, or just the incoming and outgoing relationships touching one table, sourced from information_schema and pg_constraint.
Query scaffolding
Open a SELECT template for the selected table to jump straight from browsing into editing.

security & storage

Credentials stay on your machine

Everything sensitive is stored locally and encrypted — nothing is shipped to a server that isn't yours.

Encrypted credentials
Connection secrets and API keys are encrypted at rest locally. Saved API keys take precedence over ANTHROPIC_API_KEY / OPENAI_API_KEY from your environment or .env.
Flexible TLS
Connect by fields or connection string, pick an SSL mode from disable to verify-full, and opt into self-signed certificates when a private CA needs it.
History & snippets, locally
Per-connection execution history and named snippets are kept in local storage — recent runs and reusable queries always at hand.
Local-only usage metering
Successful AI generations are counted locally by provider and model, so you can see your own usage without any telemetry leaving the app.

under the hood

How it's built

A pragmatic Electron stack, put together so the AI can be useful without ever being the weakest link in security.

ElectronNode.jsPostgreSQLPrismaZodTailwind CSS
Spec-driven
Scoped from a written PRD that distills the most valuable features of DBeaver, TablePlus, DataGrip, and Chat2DB, plus an MVP validation checklist that tracked delivery against it.
Electron architecture
A main process owns database and LLM access; a locked-down preload bridges it to the renderer over IPC. The UI never touches your database or keys directly.
Local app database
Prisma manages a local store for saved connection profiles and settings, keeping app state durable and separate from the databases you connect to.
Safety by default
AI output is always previewed, writes are gated, and destructive statements are confirmed — the model assists, but the human always pulls the trigger.

This is what I ship on my own

DB AI went from a written product spec to a working desktop app — schema-grounded AI, a full SQL workbench, and production-minded guardrails — scoped, designed, and built end to end by one product engineer. It's a fair sample of how I work: take an ambiguous problem, decide what actually matters, and ship it.