DeepSQL

The database agent for Postgres and MySQL. Point it at PostgreSQL or MySQL and ask questions in plain English — schema exploration, query generation, slow query analysis, index recommendations, generated dashboards.

You bring the model. DeepSQL ships with no model provider of its own and no vendor account to sign up for. You point it at OpenAI, Azure OpenAI, a LiteLLM proxy, or a model running on your own hardware, and it uses that. Everything else runs in your environment: database credentials are encrypted in a local vault, and nothing leaves the machines you control except the prompts you send to the endpoint you chose.

📄 Read the whitepaper — the architecture and the reasoning behind it.

📦 Latest release: v1.3.0 — DeepSQL Desktop first ship + Agent/Brain/Editor hardening. Notes: docs/releases/RELEASE_NOTES-v1.3.0.md.

---

Quick start

One-liner install

curl -fsSL https://deepsql.ai/install.sh | bash

This checks prerequisites, clones the latest release to ~/deepsql, and guides you through configuration. See scripts/self-host/remote-install.sh for options (--yes for noninteractive, --branch for a specific version).

The script source of truth is scripts/self-host/remote-install.sh in this repository. deepsql.ai/install.sh serves a copy for the homepage CTA.

Step-by-step

Five steps, in order. Budget about fifteen minutes, most of it waiting on the first build.

1. Check you have what you need

• Docker Engine with Compose v2 and buildx — verify with docker compose version and docker buildx version. Compose delegates builds to buildx and refuses anything older than 0.17.0.
• git, curl and openssl
• ~4 GB of memory available to Docker. The backend JVM is configured with a 3 GB max heap, so a smaller allocation fails in ways that look unrelated.
• An API key for a model provider. See step 3 — you need this before you start, not after.

On a fresh server, one command does all of that:

sudo ./scripts/self-host/bootstrap-server.sh

It handles Debian/Ubuntu and Amazon Linux 2023 / RHEL, installs whatever is missing, and verifies the result before exiting. Worth running even where Docker is already present: a stock dnf install docker on Amazon Linux 2023 ships neither the Compose plugin nor a buildx new enough to build, and the resulting failure surfaces much later, at docker compose up --build, naming neither.

2. Get the code

There are no prebuilt images and no container registry. Compose builds the backend and frontend from your checkout.

git clone https://github.com/DeepSQLAI/deepsql.git
cd deepsql
cp .env.example .env

3. Choose your model

This is the step that matters, and the one thing DeepSQL cannot decide for you.

Open .env and set the chat group. Whatever you pick, the provider id stays openai — there is one provider implementation and it speaks OpenAI, Azure OpenAI, and every OpenAI-compatible server. It dispatches on the shape of your endpoint, not on a name you configure.

Variable	What to put in it
DEEPSQL_CHAT_PROVIDER	openai — always, for every provider below
DEEPSQL_CHAT_API_KEY	Your key. For a local model, any non-empty string.
DEEPSQL_CHAT_ENDPOINT	The base URL. No working default — set it explicitly.
DEEPSQL_CHAT_MODEL	Model name, or your Azure deployment name

Pick the one that matches you:

DEEPSQL_CHAT_PROVIDER=openai
DEEPSQL_CHAT_API_KEY=sk-your-key
DEEPSQL_CHAT_ENDPOINT=https://api.openai.com/v1
DEEPSQL_CHAT_MODEL=gpt-4o

An .azure.com or .azure-api.net endpoint switches authentication to the api-key header automatically. _MODEL is your deployment name, not the model name.

DEEPSQL_CHAT_PROVIDER=openai
DEEPSQL_CHAT_API_KEY=your-azure-openai-key
DEEPSQL_CHAT_ENDPOINT=https://your-resource.cognitiveservices.azure.com/
DEEPSQL_CHAT_MODEL=your-deployment-name

Anthropic serves an OpenAI-compatible /v1/chat/completions, so it needs no gateway. It publishes no embeddings API, so pair it with another provider for embeddings (step 4).

DEEPSQL_CHAT_PROVIDER=openai
DEEPSQL_CHAT_API_KEY=sk-ant-your-key
DEEPSQL_CHAT_ENDPOINT=https://api.anthropic.com/v1
DEEPSQL_CHAT_MODEL=claude-haiku-4-5-20251001

Anything speaking the OpenAI wire format. No key is required, but the variable must be non-empty.

DEEPSQL_CHAT_PROVIDER=openai
DEEPSQL_CHAT_API_KEY=ollama
DEEPSQL_CHAT_ENDPOINT=http://host.docker.internal:11434/v1
DEEPSQL_CHAT_MODEL=llama3.1

Point at the proxy, authenticate with a virtual key, use your own alias. Chat, embeddings and brain initialisation are verified end to end against a self-hosted LiteLLM.

DEEPSQL_CHAT_PROVIDER=openai
DEEPSQL_CHAT_API_KEY=sk-your-litellm-virtual-key
DEEPSQL_CHAT_ENDPOINT=http://litellm:4000/v1
DEEPSQL_CHAT_MODEL=your-alias

Name your alias carefully. _USE_RESPONSES_API defaults to auto, which decides from the model name rather than from what your endpoint implements. An alias beginning gpt-5, o1, o3, o4 or codex selects the Responses API. If your gateway does not serve /v1/responses, avoid those prefixes or set DEEPSQL_CHAT_USE_RESPONSES_API=false.

DEEPSQL_CHAT_PROVIDER gates the whole group: with it unset, no other DEEPSQL_CHAT_* variable is read. That is the most common reason a carefully filled-in .env appears to be ignored.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗