DoltgreSQL：把 Git 的分支与合并带进 PostgreSQL 世界
DoltgreSQL - 版本控制的 PostgreSQL。我们使用这些相同的 Sysbench 测试来对 DoltgreSQL 进行基准测试，并将结果与 PostgreSQL 进行比较。
秒懂
- 它是什么？
- DoltgreSQL 是一个将版本控制内建到 PostgreSQL 协议中的数据库，支持分支、合并、克隆与推送。本文基于其 README 与发布信息，分析其工作机制、上手方式、性能定位与适用边界。
- 适合谁用？
- DoltgreSQL 适合那些需要把数据库状态纳入版本控制、且已经习惯 PostgreSQL 生态的团队，尤其是开发环境中的 schema 与数据迁移管理。它不适合需要完整 PostgreSQL 兼容性、依赖扩展或 GSSAPI 的生产系统，也不适合需要 DoltHub 或 DoltLab 托管的工作流。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 6 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁该关注
传统数据库只有当前状态，没有历史。你想回滚到三天前的 schema，或者对比两个分支上的数据差异，通常需要自己写迁移脚本或依赖备份。DoltgreSQL 把 Git 的版本控制模型搬进数据库：表可以分支、合并、克隆、推送和拉取。它面向的是那些把数据库当作代码一样管理的人，比如需要频繁修改 schema 的团队、做数据复现的测试工程师，以及希望把数据变更纳入代码审查流程的开发组。它的前身 Dolt 已经证明了这种思路在 MySQL 生态可行，DoltgreSQL 则是把同一套机制嫁接到 PostgreSQL 协议上。
版本控制的工作机制：从 dolt.status 到 dolt.log
DoltgreSQL 的版本控制不是外部工具，而是内建在 SQL 中的系统表与函数。你创建表、插入数据之后，可以执行 select * from dolt.status 查看变更状态，用 select dolt_add('teams', 'employees', 'employees_teams') 将表加入暂存区，然后提交。dolt.log 显示提交历史，包含 commit_hash、committer、email、date 和 message。这个流程与 Git 的 add、commit、log 一一对应，但全部通过 SQL 完成。底层存储是 Dolt 的格式，每个表的数据以类似 Git 对象的方式组织，因此分支和合并操作可以复用 Dolt 的成熟实现。值得注意的是，README 明确指出没有 Git 风格的 CLI，所有版本控制操作都必须走 SQL 接口。这意味着习惯了命令行操作的 Dolt 用户需要调整，但同时也让版本控制功能可以被应用程序直接调用。
安装与启动：一条命令，一个进程
安装 DoltgreSQL 在 Linux 和 Mac 上只需执行一条 curl 命令：sudo bash -c 'curl -L https://github.com/dolthub/doltgresql/releases/latest/download/install.sh | bash'。它会将 doltgres 二进制放到 /usr/local/bin。Windows 用户则下载 .msi 安装包。Docker 用户可以直接运行 docker run -e DOLTGRES_PASSWORD=myPassword -p 5432:5432 dolthub/doltgresql:latest。启动后，doltgres 会在当前目录创建 postgres 用户和 postgres 数据库，默认密码是 password。你可以通过环境变量 DOLTGRES_USER 和 DOLTGRES_PASSWORD 在首次运行前修改超级用户，用 DOLTGRES_DATA_DIR 或 config.yaml 指定数据目录。连接方式与 PostgreSQL 完全一致：PGPASSWORD=password psql -h localhost -U postgres。整个启动过程简单到没有配置步骤，对于想快速尝试版本控制的人来说非常友好。
性能基准：比 PostgreSQL 慢多少，文档没有给出答案
README 提到 Dolt 比 MySQL 慢 1.1 倍，用的是 Sysbench 测试，但 DoltgreSQL 的基准表格在 README 中被截断，我们看不到具体数字。这本身就是一个问题。如果你打算在生产环境使用，你需要自己跑 Sysbench 对比。文档没有给出任何关于 DoltgreSQL 与 PostgreSQL 的延迟对比数据，也没有说明在分支合并操作时的性能开销。从 Dolt 的经验推断，版本控制数据库通常会在写入路径上增加额外开销，因为每次提交都要生成对象和哈希。但 DoltgreSQL 是否继承了这种开销，或者是否做了优化，目前无法从材料中确认。我的建议是，在决定采用前，用你自己的数据量和查询模式做一次基准测试，不要依赖 README 中缺失的表格。
已知限制：Beta 状态下的缺失功能
README 明确列出多项限制。没有 Git 风格的 CLI，只有 SQL 接口。不能推送到 DoltHub 或 DoltLab，只能使用自定义远程，比如文件系统或 S3。备份和复制功能仍在开发中。没有 GSSAPI 支持，没有扩展支持。一些 PostgreSQL 语法、类型、函数和特性尚未实现。这些限制直接影响使用场景。如果你的应用依赖 PostGIS 或其他扩展，DoltgreSQL 目前无法满足。如果你需要与企业级认证集成，GSSAPI 的缺失可能成为障碍。备份和复制不完善意味着你不能把它当作高可用方案的核心。Beta 质量意味着它适合生产用例，但团队要有处理 bug 的心理准备。README 承诺大多数问题可以在 24 小时内修复，但那是商业公司的承诺，不是技术保证。
与 Dolt 的关系：同源但不同接口
DoltgreSQL 是 Dolt 的 PostgreSQL 版本，两者共享底层存储和版本控制引擎，但接口完全不同。Dolt 提供完整的 CLI，可以像 Git 一样在命令行执行 dolt branch、dolt merge、dolt push，而 DoltgreSQL 把这些操作都做成了 SQL 函数和系统表。这意味着，如果你已经熟悉 Dolt 的 CLI，迁移到 DoltgreSQL 时需要学习新的 SQL 接口。反过来，如果你从零开始，直接使用 SQL 接口可能更自然，因为不需要离开 psql 环境。另一个差异是远程支持：Dolt 可以推送到 DoltHub 和 DoltLab，DoltgreSQL 目前只能连接自定义远程。这个差异可能影响协作流程，因为 DoltHub 提供了类似 GitHub 的托管和协作功能。如果你依赖这些功能，DoltgreSQL 目前不是替代品。
维护与升级成本：Apache-2.0 下的持续更新
DoltgreSQL 采用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。项目最近发布频繁，v1.3.0 在 2026 年 8 月 28 日发布，v1.2.0 和 v1.1.0 分别在 8 月 18 日和 12 日，说明开发节奏很快。但频繁的版本更新也意味着升级成本，你需要关注每个版本的破坏性变更。Beta 阶段的功能变化可能很大，API 和 SQL 函数可能不稳定。从维护角度看，你需要定期检查 release notes，并且在自己的环境中测试新版本。由于没有扩展支持，你无法通过扩展来填补缺失功能，只能等待官方实现。备份和复制的不完善也意味着你需要额外的备份方案，这增加了运维复杂度。
编辑结论
DoltgreSQL 适合那些需要把数据库状态纳入版本控制、且已经习惯 PostgreSQL 生态的团队，尤其是开发环境中的 schema 与数据迁移管理。它不适合需要完整 PostgreSQL 兼容性、依赖扩展或 GSSAPI 的生产系统，也不适合需要 DoltHub 或 DoltLab 托管的工作流。采用前应先用 pg_dump 导入真实业务库，运行你自己的读写负载，并确认缺失的语法和函数不会阻塞关键路径。根据 README 的承诺，遇到 bug 可以提 issue，但 Beta 状态意味着你仍要准备处理未知问题。最终判断：如果你能接受 SQL 接口代替 CLI、且不需要扩展支持，DoltgreSQL 值得一试，否则等待其功能补齐更稳妥。
社区笔记