SQL Chat: a chat-based SQL client you can self-host

What SQL Chat replaces, and for whom

SQL Chat is a chat-based SQL client. The README describes it as using natural language to communicate with the database for query, modification, addition and deletion, and the repository is a TypeScript/Next.js application under an MIT licence. The intended user is someone who already has a database connection and does not want to click through a traditional client's panels to write a statement. The README frames this as rebuilding existing tools around a chat interface, and it is explicit that the premise only holds if the chat actually works.

The supported database list is short and concrete: MySQL, PostgreSQL, MSSQL, TiDB Cloud and OceanBase. That list is the first thing to check against your own stack. If your work is mostly against SQLite, ClickHouse, Snowflake or Oracle, the topics on the repository mention them, but the README's supported list does not, so treat those as unsupported until the project says otherwise. SQL Chat is not a schema migration tool and not a database administration console. It is a client, and the operations it advertises are the ordinary ones a client performs.

How the chat turns into a statement

The architecture visible in the repository is a Next.js app with a Prisma layer and an OpenAI dependency. The flow implied by the files: the browser holds a database connection configuration, the user types a request, the server sends that request plus database context to the OpenAI API, and the model returns SQL that the app then executes and renders. The README's error section confirms the OpenAI call is a live dependency of the chat path, since a failed request to the API endpoint produces a network error message with a suggestion to ping api.openai.com.

The database connection itself is configured in the UI, and the Docker documentation notes that a database on the same host must be reached through host.docker.internal rather than localhost. That is a container networking detail, not a product limitation, but it is the kind of thing that stops a first connection attempt.

Two environment variables shape where the model traffic goes. OPENAI_API_ENDPOINT defaults to https://api.openai.com, and the README points at Ollama for a self-hosted model, which means the endpoint can be redirected to your own inference server. NEXT_PUBLIC_ALLOW_SELF_OPENAI_KEY, when set to true, lets users supply their own OpenAI key instead of consuming a shared one. The README does not document how the app decides which statements are safe to execute, so if you need a review step before writes run, that is something to confirm in the source rather than assume from the description.

Installing SQL Chat with Docker and running a first query

For personal use the README gives a single Docker command. It requires two environment variables: NEXTAUTH_SECRET, which the README says must be an arbitrary string or next-auth will complain, and OPENAI_API_KEY.

docker run --name sqlchat --platform linux/amd64 --env NEXTAUTH_SECRET="$(openssl rand -hex 5)" --env OPENAI_API_KEY=<<YOUR OPENAI KEY>> -p 3000:3000 --hostname localhost sqlchat/sqlchat

After the container starts, the app listens on port 3000. Open http://localhost:3000, add a database connection in the UI, and type a question. If the database runs on the same machine as the container, the README says to use host.docker.internal as the host in the connection settings, not localhost.

To run from source instead, the README lists these steps. The package manager is pnpm.

pnpm i
pnpm prisma generate
cp .env.usedb .env

The third command copies the example environment file that assumes a database. The README also ships .env.nodb for running without one. If you skip the database, the README says you can set NEXT_PUBLIC_USE_DATABASE=false and avoid the Postgres setup entirely, which also means no account system, no per-user quota, no payment and no usage collection. When you do want those features, create a Postgres database and run the migration:

pnpm prisma migrate dev

There is an optional seed step, pnpm prisma db seed. After that, pnpm dev starts the development server, and the package.json also defines nodb and usedb scripts that load the corresponding env file through env-cmd.

The 0.0.0.0 whitelist problem on sqlchat.ai

The hosted service at sqlchat.ai connects to your database from Vercel, which the README says uses dynamic IP addresses. The practical consequence is stated plainly: you must add 0.0.0.0 to the database whitelist, allowing all connections. That is a real security decision, not a footnote. It means any host that can reach your database port is unblocked at the network layer, and the only remaining gate is the database's own authentication.

The README acknowledges the concern and points at self-hosting as the alternative. That is the honest framing, and it should drive the choice. If your database is reachable from the public internet and you cannot pin source addresses, the hosted option forces you to weaken a control you may have deliberately put in place. Self-hosting moves the connection origin inside your own network, which is why the Docker path exists. The trade-off is that you then own the OpenAI key, the uptime and the upgrades.

A second limitation is the model dependency itself. The chat path calls an OpenAI-compatible endpoint, so the quality of generated SQL tracks the model behind that endpoint. The README's troubleshooting section covers quota exhaustion and network failure to the API endpoint, which tells you these are the two failure modes users hit. Neither is a bug in SQL Chat; both are conditions of the design.

Where a traditional client still wins

A conventional SQL client such as DBeaver or pgAdmin gives you a schema tree, a query editor with completion, execution plans and a result grid you can edit cell by cell. SQL Chat replaces most of that with a text box. For exploratory questions against a schema you half-remember, the chat interface is faster. For precise work, it is slower, because you have to describe what you want and then read the generated statement to check it did what you meant.

The difference in approach matters most around writes. A traditional client shows you the statement before you run it because you wrote it. SQL Chat generates the statement, so the review step is reading model output rather than your own intent. The README does not document a confirmation gate for destructive statements, so anyone pointing this at a production database should verify that behaviour in the code first. The other practical gap is history and audit: a database console or a migration tool records what changed and when, and SQL Chat's README does not describe an equivalent trail. It is a client for getting answers, not a system of record for changes.

Maintenance, upgrades and what the MIT licence leaves you

The repository is not archived, and the last push was on 2026-04-21. There are no releases retrieved, so versioning appears to follow the main branch rather than tagged artifacts, which means an upgrade is a pull and a rebuild rather than a version bump. The Dockerfile shows the build chain: node:18-alpine, pnpm install with a frozen lockfile, next build, then a standalone runner image exposing port 3000 and starting node server.js. Prisma is generated during the build, and the production image installs openssl for it.

The practical upgrade cost sits in two places. Prisma migrations run through pnpm prisma migrate dev in development; for deployment the package.json defines build-prisma-deploy, which chains prisma generate, next build and prisma migrate deploy. If you enabled NEXT_PUBLIC_USE_DATABASE, a schema change in the app can require a migration on your Postgres instance, so the upgrade is not just a new container image. The second cost is the OpenAI dependency: model behaviour changes outside your release cycle, so the same SQL Chat version can produce different statements over time.

The MIT licence is permissive and imposes no copyleft obligation on your own code, but it also means no warranty and no support commitment from the project. The README's troubleshooting section is a list of common error messages rather than a support channel. If you need a vendor to call, this is not that.

Editorial conclusion

Adopt SQL Chat if you want a chat surface over MySQL, PostgreSQL, MSSQL, TiDB Cloud or OceanBase and you are willing to run it yourself, because self-hosting keeps credentials, schema and result sets inside your network and removes the 0.0.0.0 whitelist requirement the hosted service imposes. Do not adopt it if your databases are outside that supported list, if you need a formal audit trail of who ran which statement, or if you cannot supply an OpenAI-compatible endpoint, since the README treats OPENAI_API_KEY as a required startup option for the Docker image. Before rolling it out, verify two things: that OPENAI_API_ENDPOINT points at an endpoint you are allowed to send schema and query text to, and, if you enable NEXT_PUBLIC_USE_DATABASE, that DATABASE_URL reaches a Postgres instance whose migrations you are prepared to run.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. sqlchat/sqlchat on GitHub