# DB-GPT: an agentic data assistant that writes SQL and runs code in a sandbox

> DB-GPT connects databases, spreadsheets and knowledge bases to an LLM agent that plans analysis, generates SQL and Python, executes it in a sandbox and turns the result into reports. It is a platform, not a thin SQL wrapper, and that is both the appeal and the cost.

**eosphoros-ai/DB-GPT** — open-source agentic AI data assistant for the next generation of AI + Data products.

- Repository: https://github.com/eosphoros-ai/DB-GPT
- Website: http://docs.dbgpt.cn
- Stars: 20,067 · Forks: 2,946
- Language: Python
- License: MIT
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/eosphoros-ai-db-gpt

## The problem DB-GPT is aimed at, and who feels it

Most text-to-SQL tools stop at the query. They take a question, emit a statement, and hand it back to you to run, inspect and chart. DB-GPT is built for the step after that. The README describes it as an "open-source agentic AI data assistant" that connects to your data, writes SQL and code, runs skills in sandboxed environments, and turns analysis into reports, insights, and action. The target user is a data or platform team that wants a business user to ask a question in natural language and receive a chart, an HTML report or a summary, not a SQL string. The repository topics list agents, database, rag, llm and private, which matches that framing. It is also positioned as a build platform: the README says it is a platform for building AI-native data agents, workflows, and applications with agents, AWEL, RAG, and multi-model support. That second role matters when you decide whether to adopt it.

## How the agent actually moves from question to report

The workflow has four stages in the README: explore data, plan and execute, use skills, generate reports. In practice the data flow is: a connector brings in a database, a CSV or Excel file, a warehouse or a knowledge base; the agent plans the task and breaks it into steps; it calls tools that generate SQL or Python; those steps run in a sandboxed environment; and the outputs are assembled into charts, dashboards, HTML reports and summaries. Skills are the part that distinguishes it from a generic agent loop. The README describes them as packaged domain knowledge, analysis methods and execution workflows that can be reused, and the repository has a top-level skills/ directory plus skills.py, with an example at examples/test_skills_middleware.py. So a team can encode a recurring analysis, such as a monthly financial report, once and invoke it repeatedly instead of re-prompting from scratch. AWEL appears in the README as the workflow layer for building applications on top. The sandbox is a separate workspace package, dbgpt-sandbox, listed in pyproject.toml, which confirms that isolation is a component rather than a claim.

## Installing DB-GPT with the one-line script

The README's Quick Start gives a one-line installer for macOS and Linux. It clones into ~/.dbgpt/DB-GPT by default, and the README notes that if you already have a local checkout you can reuse it instead of cloning that path. The plain form needs no arguments:

```bash
curl -fsSL https://raw.githubusercontent.com/eosphoros-ai/DB-GPT/main/scripts/install/install.sh | bash
```

You can instead pass a profile and an API key in one line. The README shows this exact form for OpenAI, with the key passed as an environment variable and the profile selected after --:

```bash
curl -fsSL https://raw.githubusercontent.com/eosphoros-ai/DB-GPT/main/scripts/install/install.sh \
  | OPENAI_API_KEY=sk-xxx bash -s -- --profile openai
```

The README documents the same pattern for Kimi 2.5 through the Moonshot API with MOONSHOT_API_KEY and --profile kimi, and for MiniMax through the OpenAI-compatible API with MINIMAX_API_KEY and --profile minimax. Those three profiles are the ones the README names; it does not list the full set in the section shown. After installation the web UI is what you open first: the README's screenshots show a welcome page and a workspace where you connect a data source. Expect to spend your first session adding a database or uploading a CSV, not writing prompts.

## Running the Docker Compose stack instead

The repository ships a docker-compose.yml with two services. The webserver image is eosphorosai/dbgpt-openai:latest and it starts with the command dbgpt start webserver --config /app/configs/dbgpt-proxy-siliconflow-mysql.toml, so the container is driven by a TOML config file rather than flags. It publishes port 5670. The second service is a MySQL server holding DB-GPT's own metadata, initialised from ./assets/schema/dbgpt.sql. The compose file header states the requirement plainly: you should prepare the SiliconFlow API key in your environment, and the invocation is:

```bash
SILICONFLOW_API_KEY=${SILICONFLOW_API_KEY} docker compose up -d
```

The webserver reads MYSQL_HOST, MYSQL_PORT, MYSQL_DATABASE, MYSQL_USER and MYSQL_PASSWORD from the environment, with the host set to db and the port to 3306. Two operational details are worth reading before you run this. First, the compose file itself warns that the webserver may fail and must wait for all SQL files in /docker-entrypoint-initdb.d to finish, which is why restart: unless-stopped is set on both services. Second, the config directory is bind-mounted from ./configs, so the profile you run is a file you can edit rather than something baked into the image. The README does not document rollback or version pinning for either install path.

## Where DB-GPT is the wrong tool

The project describes itself in pyproject.toml as "an experimental open-source project", and that word should shape your expectations. Three constraints follow. First, DB-GPT is a platform with a web server, a metadata database and a workspace model. If your need is a function that turns a question into SQL inside your own service, you are paying for a control plane you will not use; the packages/dbgpt-client workspace member exists for programmatic use, but the README's Quick Start is entirely about the web application. Second, the isolation story is only as good as the sandbox configuration. The README says code and tools run in isolated environments, and dbgpt-sandbox is a real package, but the README does not state which isolation mechanism is used or what the default limits are. If your threat model includes untrusted prompts driving arbitrary Python, that is a gap you must close yourself before production. Third, the Docker path ties the default config to SiliconFlow and MySQL specifically. Teams standardised on Postgres for metadata, or on a provider the configs directory does not cover, will be editing TOML before the first query runs. None of this is a defect in the design; it is the normal cost of an agent platform, and it is the reason the honest answer to "can I drop this in for a quick text-to-SQL endpoint" is no.

## How it compares with wiring your own agent

The realistic alternative is not another product with the same shape; it is building the loop yourself on top of a framework such as LangChain or LlamaIndex with a SQL toolkit and a code interpreter. The difference in approach is where the work sits. In a self-built loop you write the tool definitions, the retry logic, the schema introspection, the chart rendering and the report template, and you own every one of them. DB-GPT ships those as named parts: connectors for databases and files, an AWEL workflow layer, a skills mechanism, a sandbox package and a web workspace. You trade control for a fixed vocabulary. The self-built route wins when your analysis is one narrow query pattern and you want it embedded in an existing service with no extra process. DB-GPT wins when several people need to point at different sources, reuse the same analysis repeatedly, and get a report at the end. The other practical difference is model coupling. DB-GPT's installer profiles and the compose config both assume a hosted provider by default, while the pyproject description emphasises running localized models so that data stays private. Those two facts pull in opposite directions, and the README does not resolve which deployment the project considers primary. If local inference is your reason for choosing it, confirm the model configuration path in the docs before you commit, because the quickest install path is the hosted one.

## Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-09-08. Releases are frequent: v0.8.2 on 2026-08-26, v0.8.1 on 2026-06-18 and v0.8.0 on 2026-03-27, so roughly a minor release per quarter with patches between. The version in pyproject.toml is 0.8.2, which matches the latest release tag, so the main branch and the release line are aligned rather than drifting. The project uses uv as its package manager with a workspace layout covering dbgpt-app, dbgpt-client, dbgpt-core, dbgpt-ext, dbgpt-serve and dbgpt-sandbox, plus accelerator packages. That structure means a breaking change can land in a single workspace member, and the Makefile builds a test environment with uv sync --all-packages across extras including base, proxy_openai, rag, storage_chromadb and dbgpts. Upgrading therefore means re-syncing those extras, not just bumping a version string. The licence is MIT, which is permissive and places few obligations on how you redistribute or modify it; DB-GPT also bundles a DISCLAIMER.md at the repository root, and the README does not describe what it covers, so read it if you plan to deploy this against regulated data. Nothing here is legal advice.

## Conclusion

Adopt DB-GPT if you need an agent that can query a database, run Python in a sandbox and assemble a report without sending rows to a third party, and you are willing to run a multi-service stack. Skip it if a single text-to-SQL call inside your own application is enough, because DB-GPT is a platform with a web server, a metadata store and a workspace model to operate. Before committing, verify the two things the README leaves open: which profile your model provider needs, and whether the sandbox isolation meets your own security bar.

## FAQ

### What is DB-GPT?

DB-GPT is an open-source agentic AI data assistant that connects to databases, CSV and Excel files, warehouses and knowledge bases, then lets an agent write SQL and code, run it in a sandbox, and produce charts, dashboards and reports. The README also describes it as a platform for building AI-native data agents and applications with agents, AWEL, RAG and multi-model support.

### What does GPT mean in DB-GPT?

The repository does not document the expansion of the acronym. What the README does say is that the project uses GPT large models to interact with your data and environment, and that it supports multiple model providers through installer profiles such as openai, kimi and minimax.

### Which AI is best for SQL?

The DB-GPT README does not rank models. It shows installer profiles for OpenAI, Moonshot (Kimi 2.5) and MiniMax, and the docker-compose.yml defaults to a SiliconFlow-backed config, so the project is set up to let you swap providers rather than to recommend one.

### Is SQL considered AI?

SQL itself is a query language, not an AI system. In DB-GPT the AI part is the agent that generates the SQL from a natural-language question and decides which steps to run; the SQL it produces is ordinary SQL executed against your connected data source.

### Is DBA replaced by AI?

DB-GPT does not make that claim. The README positions the agent as writing SQL autonomously and running analysis workflows, while the project still requires you to connect data sources, choose a model provider and run the web server, so the operational role it replaces is query writing rather than database administration.

## Sources

- [eosphoros-ai/DB-GPT on GitHub](https://github.com/eosphoros-ai/DB-GPT)
- [License: MIT](https://github.com/eosphoros-ai/DB-GPT/blob/main/LICENSE)
- [Project website](http://docs.dbgpt.cn)
- [README](https://github.com/eosphoros-ai/DB-GPT/blob/main/README.md)
- [Releases](https://github.com/eosphoros-ai/DB-GPT/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eosphoros-ai-db-gpt