# DeepBI: an AI-native BI platform built on a Redash fork

> DeepBI wraps conversational query generation around a PostgreSQL-backed BI stack and ships as a Docker Compose bundle. The interesting part is not the chat box, it is the fork: the frontend still reports itself as Redash.

**DeepInsight-AI/DeepBI** — LLM based data scientist, AI native data application.  AI-driven infinite thinking redefines BI.

- Repository: https://github.com/DeepInsight-AI/DeepBI
- Website: https://www.deepbi.com/
- Stars: 2,382 · Forks: 371
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/deepinsight-ai-deepbi

## What DeepBI actually replaces in a BI workflow

The pitch is that a user asks a question in a chat window and gets back data, a chart, or a saved query. The README describes this as "Conversational data analysis" and "Conversational query generation", with dashboards assembled from the visualizations that survive the conversation. That is a narrower claim than it first appears. DeepBI is not replacing the warehouse, and it is not replacing the transformation layer. It sits where a self-serve BI tool would sit: between a person and a database they do not want to write SQL against.

The target user is the analyst who fields the same ad hoc questions all week, or the operator who has a MySQL or Doris instance and no one to build a semantic model over it. The README lists MySQL, PostgreSQL, Doris, StarRocks, MongoDB and CSV/Excel import as supported sources. That list matters more than the chat interface, because each connector is a maintenance surface. A project that supports six engines has six sets of dialect quirks to handle when a model generates SQL.

One feature is explicitly unfinished. Automated data analysis reports are marked "to be developed" in the feature list. Treat the shipped product as conversational query generation plus dashboards, not as an automated reporting engine.

## The architecture visible in docker-compose.yml

The compose file is the clearest documentation the repository offers. It defines six services plus two backing stores and a mail catcher. The server service publishes 8338, a server_socket service publishes 8339, and a server_ai_api service publishes 8340. The README only mentions 8338 and 8339 as default ports, so the AI API port is documented in the compose file rather than in the install instructions.

The processes are split the way a Redash-derived stack splits them: server, scheduler, worker, plus the socket service for live updates. The worker and scheduler run Celery jobs, and the compose environment sets DEEPBI_CELERY_WORKERS to 4 and DEEPBI_WEB_WORKERS to 4. That is a fixed number, not a formula. On a 2-core machine, which the README gives as the minimum, four web workers and four Celery workers will contend for the same cores.

Storage is Redis 3 and PostgreSQL 14. The Postgres container is started with fsync=off, full_page_writes=off and synchronous_commit=OFF, and with POSTGRES_HOST_AUTH_METHOD set to trust. Those settings trade durability and authentication for speed in a local or demo deployment. Running that same compose file on a host reachable from a network is a decision worth making deliberately. The README does not discuss hardening the compose stack.

## Installing DeepBI with Docker Compose

The README gives a Docker path and a Windows executable path. The Docker path needs docker and docker-compose present. Clone the repository and enter it:

```bash
git clone https://github.com/DeepInsight-AI/DeepBI.git
cd DeepBI
```

Then run the install script. The README says to run it directly, with no arguments and no flags.

```bash
./Install.sh
```

After the stack comes up, the README says the default ports are 8338 and 8339 and that the web interface is at http://ip:8338. The compose file adds a third published port, 8340, for the AI API service. Day-to-day control uses the compose commands the README lists:

```bash
docker-compose start
docker-compose stop
docker-compose ps
```

The README notes that a PermissionError or Permission denied means you should prefix the command with sudo, and gives the sudo variants explicitly. If you prefer the Makefile, it wraps the same operations: make up runs docker-compose up -d --build, make down stops the stack, and make bash opens a shell inside the server container. The Makefile also has a create_database target that runs create_db inside the server container, which is the step you need before the web interface has anything to connect to.

The Windows route is different: download window_install_exe_EN.zip from the releases list, unzip, and double-click the .exe. The README states the tested targets are Win10 and Win11.

## The Ubuntu path and its version pinning

Installing directly on Ubuntu bypasses Docker and requires more from you. The README states you need Redis reachable at 127.0.0.1 without a password, PostgreSQL 16, and Python 3.8.x, and it recommends a virtual environment such as pyenv or conda. Then it tells you to run:

```bash
. ubuntu_install.sh
```

The leading dot is deliberate and the README calls it out: you must source the script rather than run it with sh, because the script needs to activate the Python virtual environment in your current shell. Running sh ubuntu_install.sh will not do the same thing.

The Python pin is the constraint to notice. The README says 3.8.x, and the repository carries a vrequment.txt alongside setup.cfg. Python 3.8 is old enough that many current libraries have dropped it, so you are installing into an environment you may not be able to upgrade piecemeal. If your host already runs a newer Python for other services, the sourced virtual environment is not optional, it is the only thing keeping the two apart. The README does not describe what happens if the system Python is 3.11.

## Where DeepBI is the wrong tool

Generated SQL is hard to review, and DeepBI's documentation does not describe a review step. If your organisation requires that every query touching production data be attributable to a named author and retained, the README offers nothing on that front. There is no mention of a query audit log, a SQL approval queue, or a read-only enforcement layer at the application level. You would be relying on the database account you hand to DeepBI, which is the right place to enforce it anyway, but the project does not tell you to.

The second limitation is operational. The compose file pins Redis 3, which is a very old major version, and PostgreSQL 14. The README's Ubuntu instructions ask for PostgreSQL 16. Those two paths do not agree, so a bug that appears under Docker may not reproduce on Ubuntu and vice versa. For a self-hosted deployment that divergence is a real cost when you are trying to file a useful issue.

Third, the AI API service on port 8340 is not covered in the README's install section. If you firewall the host, you need to know it exists. Read docker-compose.yml before you expose the machine.

Finally, if your data lives in a warehouse with a mature semantic layer and governed metrics, DeepBI is solving a problem you have already solved. Pointing an LLM at raw tables when a curated model already exists adds a second, less predictable path to the same numbers.

## DeepBI versus Redash, and why the fork matters

The package.json in client/ is the tell. Its name field is "client", its repository URL points at git+https://github.com/getredash/redash.git, its bugs URL points at the Redash issue tracker, and its license field reads BSD-2-Clause. DeepBI's own LICENSE file is MIT. The frontend is a Redash fork, and the compose service names (server, scheduler, worker) follow the same lineage.

That is the honest comparison. Redash is a query-and-dashboard tool where a human writes the SQL and schedules the refresh. DeepBI keeps that substrate and puts an LLM in front of it to generate the query from a conversation. The difference in approach is who writes the SQL. With Redash, the query is the artifact and it is reviewed by whoever wrote it. With DeepBI, the query is generated, and the artifact is the conversation plus whatever visualization you chose to persist.

If you want scheduled, human-authored queries against many sources, Redash is the smaller and better-understood system, and DeepBI inherits most of its operational shape anyway. If the bottleneck is that nobody on the team wants to write the SQL at all, the generation layer is the whole point and the fork is just plumbing. What you should not assume is that DeepBI's frontend has diverged enough from Redash to be maintained independently of it. The package.json still points home.

## Maintenance, licensing and upgrade cost

The last push to the repository was on 2026-08-28, which is recent. The most recent tagged release, however, is v2.0.4 from 2024-10-08, with v2.0.3 before it in June 2024 and v2.0.2 in June 2024. So there is active commit activity on main with no corresponding release for a long stretch. If you deploy by tag, you are deploying code from 2024. If you deploy from main, you are deploying untagged code. The README does not document rollback, and there is no migration guide in the repository listing, so an upgrade from one commit to the next is something you work out from the diff.

On licensing: the repository's LICENSE is MIT, which is permissive. The client/package.json declares BSD-2-Clause and names Redash as its upstream repository. Two different licence identifiers appear in the same tree. I am not a lawyer and this is not legal advice, but the practical step is to read both LICENSE and client/package.json before you redistribute anything, and to check whether the Redash-derived frontend carries notice requirements that the MIT file alone does not satisfy. For internal self-hosted use this is usually a non-issue; for a product you ship, it is worth ten minutes.

Upgrade cost otherwise comes down to the database. The compose file runs Postgres 14 with fsync disabled, and the README's Ubuntu path asks for Postgres 16. Moving a deployment between those two paths means a dump and restore, and the repository listing shows no migration tooling beyond the create_db command the Makefile invokes.

## Conclusion

Adopt DeepBI if you already run PostgreSQL, Redis and a warehouse you can point a read-only account at, and you want conversational query generation without writing a semantic layer. Do not adopt it if you need an audit trail on generated SQL, because the README does not document one. Before installing, open client/package.json and confirm the fork lineage against your own licence obligations, then check that your Python environment is 3.8.x, since ubuntu_install.sh assumes it.

## FAQ

### What is DeepBI?

DeepBI is an AI-native data analysis platform that uses large language models to explore, query, visualize and share data from sources including MySQL, PostgreSQL, Doris, StarRocks, MongoDB and CSV/Excel imports. It ships as a Docker Compose stack and as a Windows executable.

### How can deep learning be used for data analytics?

In DeepBI the language model turns a conversation into a query and a visualization rather than having the user write SQL. The README calls this conversational data analysis and conversational query generation, with persistent visualizations assembled into dashboards.

### What is deepbite?

There is no product called deepbite in this project; the repository covered here is DeepBI, an AI-native data analysis platform from DeepInsight-AI. Its README documents conversational query generation, dashboards and connectors for MySQL, PostgreSQL, Doris, StarRocks, MongoDB and CSV/Excel.

### Is deep bite normal?

That question concerns a dental condition, not DeepBI, and nothing in the DeepBI README addresses it. DeepBI itself is a data analysis platform whose README documents installation through Docker Compose or a Windows executable.

### Is deep bite bad?

That question concerns a dental condition, not DeepBI, and nothing in the DeepBI README addresses it. For DeepBI itself, the README states a minimum server requirement of 1 core and 2 GB of memory, with 2 cores and 4 GB recommended.

## Sources

- [DeepInsight-AI/DeepBI on GitHub](https://github.com/DeepInsight-AI/DeepBI)
- [License: MIT](https://github.com/DeepInsight-AI/DeepBI/blob/main/LICENSE)
- [Project website](https://www.deepbi.com/)
- [README](https://github.com/DeepInsight-AI/DeepBI/blob/main/README.md)
- [Releases](https://github.com/DeepInsight-AI/DeepBI/releases)

---

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