DeepBI: an LLM front end for MySQL, PostgreSQL, Doris and StarRocks
LLM based data scientist, AI native data application. AI-driven infinite thinking redefines BI.
At a glance
- What is it?
- DeepBI is a Python and Docker application that turns natural language questions into queries, charts and dashboards against six data source types. The install path is short, the Python version is pinned hard, and the automated report feature is still marked as unbuilt.
- Who is it for?
- Adopt DeepBI if you already run MySQL, PostgreSQL, Doris, StarRocks or MongoDB and want a conversational layer that writes persistent queries and dashboards without a separate semantic model. Do not adopt it if you need automated report generation, since the README lists that feature as still to be developed, or if you cannot pin Python 3.8.x and PostgreSQL 16 on the host.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 19 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap DeepBI targets between a warehouse and a chart
Most BI tools assume someone has already modelled the data. You define dimensions and measures, build a semantic layer, then hand analysts a drag-and-drop surface. DeepBI inverts that. The README describes it as an AI-native data analysis platform where users get "arbitrary data results and analysis results through dialogues", and the queries themselves are generated from those dialogues rather than assembled from pre-declared fields. The intended user is someone who has a database and a question but no interest in maintaining a metrics catalogue. The README also lists CSV and Excel import alongside MySQL, PostgreSQL, Doris, StarRocks and MongoDB, so the entry point can be a flat file rather than a live warehouse. That matters because it lowers the setup cost to almost nothing for a first evaluation. The project is MIT licensed and written in Python, with a commercial homepage at deepbi.com and separate developer and business contact addresses in the README, which suggests the open repository is the distribution channel rather than the whole product.
How conversation becomes a persistent query and a dashboard
The README splits the workflow into three named features that build on each other. Conversational data analysis produces one-off results and analysis. Conversational query generation turns an exchange into a query and a visualization that persists, which is the important distinction: the output is not a chat transcript but an artifact you can return to. Dashboards then collect those persistent visualizations into a single view. The repository topics list redis alongside mysql and gpt, and the Ubuntu instructions require a local Redis reachable password-free on 127.0.0.1, which is consistent with Redis holding session or task state while PostgreSQL holds the application's own metadata. The README does not document the internal request path, so anything beyond that is inference. What is documented is the surface: six connection types, two default ports (8338 for the web interface and 8339 alongside it), and a user manual shipped in the repository at client/app/assets/images/en/user_manual_en.md. If you want to know how a generated query is stored or versioned, that manual is the place to look, because the README does not answer it.
Installing DeepBI with Docker, or on Ubuntu with Python 3.8.17
The Docker route is the one the README leads with. Clone the repository with git clone https://github.com/DeepInsight-AI/DeepBI.git, enter the directory with cd DeepBI, then run ./Install.sh. The web interface answers on http://ip:8338. Day-to-day control is three docker-compose commands: docker-compose start, docker-compose stop and docker-compose ps. The README notes that a PermissionError or Permission denied means you should prefix those with sudo. There is also a Windows path: download window_install_exe_EN.zip from the releases page, unzip, and double-click the .exe, with Win10 and Win11 listed as the tested targets. The Ubuntu path is stricter. It requires Redis reachable without a password on 127.0.0.1, PostgreSQL 16 specifically, and Python 3.8.x, with 3.8.17 named in the heading. You run it as . ubuntu_install.sh, not sh ubuntu_install.sh, and the README explains why: the leading dot keeps the script inside the shell so the Python virtual environment survives. That single character is the most common way this install fails. pyenv or conda is recommended for isolating the interpreter. The README states a minimum of 1 core and 2 GB of memory, with 2 cores and 4 GB recommended, and lists testing on Mac OS 12.7, 13.x and 14.1.1, Ubuntu 20.04 and 22.04, and Windows 11 WSL 22.04.
The Python 3.8 pin and the unbuilt report feature
Two constraints stand out. The first is the interpreter. Python 3.8 reached end of life, and the Ubuntu instructions name 3.8.17 in the section heading and 3.8.x in the body. That means the non-Docker deployment is tied to an interpreter version most teams have already moved past, and running it means either keeping a 3.8 environment alive or accepting the container as the only realistic deployment. The second is the feature list itself. Item four, automated data analysis reports, carries the parenthetical "to be developed". If automated narrative reporting is the reason you are evaluating DeepBI, the README is telling you it is not there yet. The README also does not discuss what happens when the language model produces SQL that is syntactically valid but semantically wrong. There is no documented validation step, no mention of a dry run, and no stated guardrail on generated queries. For a read-only analytics user that is a quality problem. For anyone pointing DeepBI at a connection with write permissions, it is a permissions problem, and the README gives no guidance on restricting the account. Treat the database credentials you supply as the only real boundary.
Where DeepBI fits against Metabase and Superset
Metabase and Apache Superset occupy the same shelf but start from the opposite premise. Both expect a human to define the questions: Metabase through a question builder and saved questions, Superset through charts and SQL Lab. The model is the source of truth, and the tool renders it. DeepBI removes that modelling step and asks the LLM to produce the query from the conversation each time. The trade-off is reproducibility. A saved Metabase question returns the same number tomorrow because the SQL is fixed and reviewable. A DeepBI conversation produces a query whose correctness depends on the model's reading of your schema, and the README does not describe how or whether that query is surfaced for inspection before it runs. DeepBI's advantage is coverage of sources that Metabase and Superset do not treat as first-class in the same way, specifically Doris and StarRocks, which appear in the supported list alongside the more common MySQL, PostgreSQL and MongoDB. If your warehouse is Doris or StarRocks, that list is the concrete reason to look here rather than at a general-purpose BI tool.
Upgrades, maintenance and the MIT licence
The release history is short and unevenly spaced: v2.0.2 in June 2024, v2.0.3 later the same month, v2.0.4 in October 2024. The repository itself shows a push in August 2026, so commits continue between tagged releases. That pattern means the tagged versions are not a reliable proxy for the current state of main, and anyone pinning to v2.0.4 should read the commits that follow it rather than assuming the tag is the frontier. Operationally you are maintaining a Docker Compose stack plus PostgreSQL 16 plus Redis, or the same three components installed by hand. The upgrade procedure is not documented in the README beyond the compose commands, so a version bump means re-running ./Install.sh or . ubuntu_install.sh and hoping the schema migrations are handled inside. The MIT licence is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the repository's terms, not advice about your situation. One practical consequence is that a vendor can fork DeepBI, and DeepBI's own commercial offering at deepbi.com sits alongside the same code under the same permissive terms, which is worth understanding before you build a support relationship around it.
Editorial conclusion
Adopt DeepBI if you already run MySQL, PostgreSQL, Doris, StarRocks or MongoDB and want a conversational layer that writes persistent queries and dashboards without a separate semantic model. Do not adopt it if you need automated report generation, since the README lists that feature as still to be developed, or if you cannot pin Python 3.8.x and PostgreSQL 16 on the host. Before committing, confirm on your own hardware that the LLM you intend to point it at returns valid SQL against your schema, and check the v2.0.4 release notes for anything the README has not caught up with.
Community notes