DeepBI：把自然语言接到数据库上的开源 BI 平台，值不值得自建
LLM based data scientist, AI native data application. AI-driven infinite thinking redefines BI.
秒懂
- 它是什么？
- DeepBI 用 LLM 把自然语言转成查询、图表和看板，支持 MySQL、PostgreSQL、Doris、StarRocks 等数据源。它解决的是业务人员写不出 SQL 的问题，但代价是一整套自托管服务，以及一个尚未完成的报告模块。
- 适合谁用？
- DeepBI 适合已经有 MySQL、PostgreSQL、Doris 或 StarRocks 数据源，且愿意自己维护一套 docker-compose 服务、把数据库凭据交给它的团队；不适合只想零运维试用、或需要一个已完成自动报告功能的人，因为 README 明确把自动数据分析报告标为 to be developed。上手前先确认三件事：python 版本必须是 3.8.x，PostgreSQL 需要 16 版本，以及目标数据库的连接方式是否在 README 列出的范围内。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 19 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是谁写 SQL 的问题，不是数据存哪的问题
传统 BI 的门槛不在图表，而在从问题到查询的那一步。业务方想知道上周哪个渠道的复购率掉了，得先找人写 SQL，再等排期做图。DeepBI 的定位就是把这层翻译交给 LLM：README 的第一条功能写的是 conversational data analysis，用户通过对话拿到数据结果和分析结果，第二条是 conversational query generation，通过对话生成可持久化的查询和可视化。
目标用户因此很明确：手里已经有 MySQL、PostgreSQL、Doris、StarRocks 或 CSV/Excel 数据，但没有专职数据分析师随时待命的中小团队。它不负责数据采集，也不负责数仓建模。README 列出的支持数据库是 MySQL、PostgreSQL、csv/Excel Import、Doris、StarRocks、MongoDB，注意这里有个细节：Doris 和 StarRocks 是分析型数据库，说明作者预期的场景是数据已经在数仓里、只是取数环节卡住了。
如果你的数据还散在业务库的几十张表里、字段命名混乱，DeepBI 帮不上忙。LLM 生成查询的质量取决于它对表结构的理解，而表结构本身混乱是数据治理问题，不是对话层能补的。
对话到图表之间隔了一层持久化对象
从 README 的功能描述可以还原出一条清晰的链路：对话产生查询，查询被固化成可持久化的查询和可视化，可视化再被组装进 dashboard。这个设计的关键在于中间那层持久化。
很多同类工具是纯对话式的，问一次答一次，结果不落盘。DeepBI 选择把每次对话的输出沉淀成对象，好处是看板不是截图，而是引用查询定义，数据更新后看板跟着更新。代价是用户得理解查询和可视化是两回事：改可视化样式不会动查询，改查询会牵动所有引用它的图表。README 没有展开这层依赖关系怎么管理，用户手册在 client/app/assets/images/en/user_manual_en.md，具体行为需要自己去翻。
多语言支持也在功能列表里，中文和英文都在支持范围内，这对国内团队算是个实际便利，至少不用先过一遍翻译。
部署：一条 Install.sh 和一组 docker-compose 命令
DeepBI 提供两种主要部署路径。Windows 用户可以直接下 window_install_exe_EN.zip，解压后双击 exe，README 说明当前测试支持 Win10 和 Win11。Linux 和 Mac 走 Docker 或 Ubuntu 原生安装。
Docker 路径的命令是明确给出的。先克隆仓库：
git clone https://github.com/DeepInsight-AI/DeepBI.git
进入目录后执行：
cd DeepBI ./Install.sh
默认端口是 8338 和 8339，Web 访问地址是 http://ip:8338。日常运维用三条命令：docker-compose start、docker-compose stop、docker-compose ps。README 特别提醒，如果遇到 PermissionError 或 Permission denied，需要在命令前加 sudo。
Ubuntu 原生安装的约束更硬。需要预先装好 redis、postgresql 和 python3.8.17 环境。Redis 要能通过 127.0.0.1 免密命令行访问；python 版本要求 3.8.x，README 建议用 pyenv 或 conda 建虚拟环境；PostgreSQL 需要装 postgresql-16 版本。安装脚本的调用方式有个容易踩的坑：要用 . ubuntu_install.sh 而不是 sh ubuntu_install.sh，因为需要激活 python 虚拟环境。
资源方面，README 给出的最低要求是 1 核 2G 内存，推荐 2 核 4G。这个数字对自托管服务来说不算高，但要注意它只是服务本身的占用，不含数据库。
python 3.8.x 和 PostgreSQL 16 是两个硬约束
上面两条版本要求值得单独拎出来说，因为它们决定了 DeepBI 能不能装进你现有的环境。
python 3.8.x 意味着不能直接用系统自带的 python3。Ubuntu 22.04 默认是 3.10，20.04 默认是 3.8，所以 README 才会建议 pyenv 或 conda。如果你的服务器上已经跑着别的 python 服务，版本冲突要靠虚拟环境隔离，不能靠改系统解释器。
PostgreSQL 16 同样是个门槛。README 写的是 needs to install postgresql-16 version，注意这里说的是 16，不是 16 以上。Ubuntu 20.04 的官方源里没有 PostgreSQL 16，需要加 PGDG 源。这一步 README 没有展开，属于文档偏薄的地方，实际部署时大概率要自己查。
还有一个隐含约束：DeepBI 自己需要一个 PostgreSQL 来存元数据，同时又要连你的业务数据库。也就是说一次部署至少涉及两个数据库实例，如果业务库是 PostgreSQL，别把两个搞混了。
自动报告还没做完，别按宣传语做规划
功能列表里第四条写着 Automated data analysis reports (to be developed)，括号里是原文。这条必须说清楚：一个把自动报告当卖点的平台，报告模块目前是未完成状态。做技术选型时，如果自动周报、自动归因是你最看重的能力，DeepBI 现在给不了。
其余几条功能没有标注未完成，但 README 也没有给出精度、延迟或失败率方面的任何数据，这些只能靠实际部署后自己测。
另一个需要留意的地方是架构上的必然代价：DeepBI 要生成查询，就必须拿到数据库的连接信息和表结构。这意味着你的数据库凭据会存在 DeepBI 的配置里，而它本身是个 Web 服务。README 没有说明凭据的加密方式，也没有提权限最小化的做法。生产环境接入前，建议单独开一个只读账号，只授权需要的库表，不要图省事用主账号。这是部署层面的判断，不是对项目代码的指控。
和直接让 LLM 写 SQL 相比，差别在持久化
最直接的替代方案是把表结构贴给通用 LLM，让它生成 SQL，自己拿去数据库跑。这条路零部署成本，对一次性取数完全够用。
差别在于三点。第一是持久化：DeepBI 把查询固化成对象，可以反复执行、组装进看板；聊天窗口里的 SQL 是一次性的，下次还得重新问。第二是连接：DeepBI 直接连 MySQL、PostgreSQL、Doris、StarRocks，省掉复制粘贴和执行结果回传的环节。第三是协作，看板可以分享，聊天记录不行。
反过来说，如果你的需求是每周跑一次固定报表，用 cron 加一段写死的 SQL 更省事，也更可控。DeepBI 的价值在探索性分析，也就是问题事先不知道、需要来回追问的场景。
它和传统 BI 工具的关系也不同。传统 BI 靠拖拽维度和度量，语义层是预先建模好的，结果稳定但灵活性差；DeepBI 靠 LLM 现推查询，灵活但结果依赖模型对表结构的理解。两条路线的取舍是稳定性换灵活性，不存在哪边全面占优。
MIT 许可和升级成本
DeepBI 采用 MIT 许可证，这是宽松型许可，允许修改、分发和商用，义务主要是保留版权声明和许可文本。需要注意 README 里出现了两个邮箱，dev@deepbi.com 和 hi@deepbi.com，以及一个商业站点 deepbi.com，说明项目背后有商业实体在运营。MIT 许可本身不限制你把代码用在自己的产品里，但如果后续要依赖官方支持或托管服务，那就属于商业关系，和许可证是两回事。具体条款适用请以仓库中的 LICENSE 文件为准，这里不构成法律意见。
升级方面，最近的发布是 v2.0.4（2024-10-08），往前是 v2.0.3（2024-06-21）和 v2.0.2（2024-06-14）。版本号节奏在 2.0.x 上，属于小版本迭代。仓库最后一次 push 是 2026-08-28，说明代码仍在维护。
自托管的升级成本主要落在数据库和 python 环境上。PostgreSQL 16 和 python 3.8.x 这两个约束会随着时间推移变成负担，因为 python 3.8 已经进入生命周期末段，而新版操作系统默认不带它。每次升级 DeepBI 之前，都要先确认它有没有放宽版本要求。Docker 路径在这方面省事一些，镜像里已经把依赖打包好了，代价是出问题时排查链路更长。
编辑结论
DeepBI 适合已经有 MySQL、PostgreSQL、Doris 或 StarRocks 数据源，且愿意自己维护一套 docker-compose 服务、把数据库凭据交给它的团队；不适合只想零运维试用、或需要一个已完成自动报告功能的人，因为 README 明确把自动数据分析报告标为 to be developed。上手前先确认三件事：python 版本必须是 3.8.x，PostgreSQL 需要 16 版本，以及目标数据库的连接方式是否在 README 列出的范围内。如果这三条都满足，再跑 ./Install.sh，默认 Web 端口是 8338。
社区笔记