FerretDB 最容易被讲偏的时候，往往是它被说得过于宽泛。若把它压成一句“运行在 PostgreSQL 之上的 MongoDB”，这句话当然好记，失真也随之出现。项目本身更窄，也更有意思。FerretDB 在文档里把自己定义为 MongoDB 的开源替代方案：它接收 MongoDB 5.0+ 的 wire protocol 请求，把这些查询转换成 SQL，再把 PostgreSQL 连同 DocumentDB extension 作为数据库引擎放在底层。[1][8] 这样一来，真正需要回答的问题就不再是“它能不能替掉所有 MongoDB 部署”，而是“你的团队是否想把 MongoDB 一侧的应用与工具习惯保留下来，同时把存储与运维重心拉回 PostgreSQL”。[1][2]

正因为这一层区分够清楚，这个项目在 2026 年值得单独写一篇介绍。截至 2026-04-28T18:05:41Z UTC，GitHub API 显示 FerretDB/FerretDB 仓库有 10,922 stars、475 forks、442 个 open issues，最近一次 push 时间是 2026-04-24T20:46:10Z。[7] 最近一个稳定标签是 v2.7.0，发布时间为 2025-11-10。[6] 这些数字当然不能替你完成技术判断，却足以说明，FerretDB 已经并非一场停留在理念层的许可证抗议，而是一套有人在持续维护、有人在真实使用的兼容性工程。

配图说明：题图没有使用数据库示意图，也没有使用泛泛的机房照片，而是选了一张 FerretDB 官方团队页上的 Peter Farkas 肖像。这是合适的，因为本文是一篇关于项目边界与运维适配面的介绍。真正重要的，是维护者如何把 MongoDB 兼容面与 PostgreSQL 现实放在同一套叙述里。[9]

你真正采用的是什么

介绍页与 GitHub README 对架构的描述几乎完全一致：应用与驱动用 MongoDB 协议和 BSON 对 FerretDB 说话，FerretDB 再用 PostgreSQL 协议和 SQL 去连接底层带有 DocumentDB 的 PostgreSQL。[1][8] 这项设计最有价值的地方，在于它把产品边界摆得很直白。FerretDB 没有要求你把应用改写成另一套查询接口，它要求你在 MongoDB 风格客户端与 PostgreSQL 背后的文档存储之间，加入一层兼容代理。

这份合同适合一类很具体的团队。有些组织已经拥有写成 MongoDB 形状的应用代码、管理工具与日常习惯，同时又更愿意把长期的数据运维留在 PostgreSQL 这条线上，而不想再养一套独立的 MongoDB 平台。FerretDB 正是在这个中间位置上成立的。[1][8] 文档里写得也很克制：它能够在很多场景里直接替代 MongoDB 5.0+，真正进入生产之前，仍然要对照你的应用去验证是否合适。[1]

这句提醒很重要。FerretDB 最强的时候，是你把它当成一项明示边界的兼容工程来读，而并非把它看成一把能把所有数据库问题熔成一块的万能钥匙。顺着这条方式往下读，它的价值会清楚得多，也稳得多。

运行中心仍然留在 PostgreSQL

FerretDB 真正有吸引力的深层原因，在于它的存储与可靠性故事始终压在 PostgreSQL 身上，而没有另起一套新的控制面。复制指南写得很明确：当前的复制支持沿用 PostgreSQL 的 WAL streaming 模型，主库负责写入，只读副本跟随其后，FerretDB 只是分别指向这些 PostgreSQL 端点。[4] 文档中的示意拓扑也非常说明问题。真正的核心部件是 postgres_primary、postgres_replica、ferretdb 与 ferretdb_readonly，FerretDB 通过 PostgreSQL URL 完成配置，中间没有再长出另一套独立的集群编排体系。[4]

放在运维层看，这一点价值很大，因为最硬的持久性与故障切换问题，仍然落在很多团队已经熟悉的 PostgreSQL 机制里。若你的团队已经懂 WAL、pg_basebackup、副本提升，以及主读写和只读流量的区分，FerretDB 不会要求他们把这些知识丢掉。[4] 它是在这套基础之上，再覆盖一层文档数据库兼容面。

可观测性也沿着同样的方向展开。FerretDB 提供结构化日志、OTLP traces、Prometheus 格式指标，以及 /debug/livez 和 /debug/readyz 端点。[5] 尤其值得注意的是 readiness probe：它检查 MongoDB 客户端能否通过 FerretDB 连通，同时也检查 PostgreSQL 与 DocumentDB 是否安装正确。[5] 这条探针本身就暴露了项目对自己位置的理解。协议桥是它负责的那一层，真正的底层健康判断，最后仍然要回到 PostgreSQL 加 DocumentDB 这一组组合上。

所以，我更愿意把 FerretDB 叫作“以 PostgreSQL 为运维中心”的项目，而并非一套独立的文档数据库平台。它最强的叙述，不在新鲜感，落在运行面足够清楚、足够可追踪。

兼容面已经足够有分量，边界也仍然需要逐项核对

FerretDB 一旦把兼容表读进去，项目就会立刻变得具体。文档写明，所有兼容 MongoDB 5.0+ 的驱动与应用，在 wire protocol 这一层都应当兼容；命令覆盖面也已经不小，find、insert、update、delete、aggregate、explain、serverStatus、createIndexes、listIndexes 与不少用户管理操作都已经支持。[2] 另一页“Compatible applications”继续把这件事落到实际软件上：FerretDB 团队已经测试过 DBeaver、Studio 3T 这类 GUI 工具，Grafana 与 OpenTelemetry 这类观测工具，dsync 这类迁移工具，以及 Payload CMS、NodeBB、LibreChat、GrowthBook、HashiCorp Vault 这类更靠近产品层的应用。[3]

也正因为这样，项目才值得认真看。FerretDB 现在关心的，已经不再是“一个 demo app 能不能连上”，而是“一个真正按 MongoDB 生态写成的软件，能不能在这张兼容表面上跑起来”。[2][3] InfoQ 在总结 v2.0 版本时抓到的也是这一层：性能改进、功能兼容面的扩大、复制支持以及向量搜索相关能力，才是这次版本真正重要的地方，而并非“又多了一个 MongoDB alternative”这句空话。[10]

边界同时也非常具体，文档没有掩饰。bulkWrite 还没有实现，事务相关的 abortTransaction 与 commitTransaction 还没有实现，大部分角色管理命令仍然缺席；连在错误码和错误名能够对齐 MongoDB 的地方，文档也会提醒你，精确错误信息仍然会有差异。[2] 这些内容都并非无伤大雅的小字脚注，它们决定了项目适合先在哪些场景里试，哪些迁移则需要把速度压下来。

较稳妥的读法因此也很清楚：FerretDB 的兼容面已经广到足以支撑真实工作负载，边界也仍然窄到必须做 pre-migration testing。这对一项以兼容为核心的开源项目来说，是一种健康状态。真正危险的做法，反而是装作这张矩阵已经不再重要。

最强适配面，是“应用沿用 MongoDB，运维回到 PostgreSQL”

FerretDB 最合适的场景，大多都聚集在一类系统上：应用边缘还保持着 MongoDB 的形状，运维中心则已经是 PostgreSQL。它可以是上游原本为 MongoDB 写好的自托管产品，也可以是内部工具，依赖 MongoDB 驱动与管理界面来运行，还可以是那些更愿意把复制、监控、打包与运维经验留在 PostgreSQL 生态中的部署环境。[1][3][4][5]

安装路径也支持这种理解。FerretDB 可以通过 Docker、Kubernetes、.deb、.rpm 包来部署，还可以作为 Go 包嵌入应用。[6] 这组选择说明，项目试图承接的是已经存在的运维现实，而并非假定一条唯一、单一的云端路径。它最有力的采用楔子，在应用边界上的兼容便利，也在底层运维层面的熟悉感。

不合适的地方同样清楚。若你的应用依赖完整的 MongoDB 长尾语义，需要成熟的事务支持，或者强依赖兼容表中仍标记为未完成的管理命令，FerretDB 就不会是低风险答案。[2] 另一类不合适的情况，是团队本身并不想让 PostgreSQL 继续留在中心位置。这样一来，这层兼容代理就会从简化系统的一层，变成系统里额外多出来的一层。

第一次试点怎样落地

FerretDB 这类项目，最值得的第一步一直都很窄。先挑一个已经说 MongoDB 的应用，对照兼容列表核它的热路径命令，用 Docker 或 Kubernetes 立起来，再把复制与健康检查严格对齐 PostgreSQL 的常规做法。[2][4][6] 然后问一个非常直接的问题：在应用与工具表面继续保持 MongoDB 形状、在存储与运维中心回到 PostgreSQL 之后，这个团队是否确实得到了足够多的好处？

这个问题比抽象争论数据库信仰更有价值。FerretDB 不需要在抽象层面“战胜 MongoDB”，它只需要替适合它的团队解决一个真实边界问题。到了 2026 年，这个边界已经清楚到值得认真看待：边缘是 MongoDB 兼容面，底下是 PostgreSQL 的运维引力，文档又足够诚实，让你能看清承诺到底停在哪里。[1][2][4][5][10]

来源

1. FerretDB 文档《Introduction》——项目定义、wire protocol 转换模型、MongoDB 5.0+ 范围，以及进入生产前需验证适配性的提醒。
2. FerretDB 文档《Compatibility》——已支持命令、已知限制，以及事务、角色管理和 bulkWrite 等尚未实现的边界。
3. FerretDB 文档《Compatible applications》——已经测试过的 GUI 工具、观测工具、迁移工具和上层应用列表。
4. FerretDB 文档《Replication》——基于 PostgreSQL WAL streaming 的复制模型、主从布局，以及读写与只读 FerretDB 实例的示例拓扑。
5. FerretDB 文档《Observability》——结构化日志、OTLP traces、Prometheus 指标，以及 /debug/livez 与 /debug/readyz 健康检查端点。
6. FerretDB/FerretDB 的 GitHub release 页面——最新稳定标签 v2.7.0、发布时间，以及打包发布物。
7. FerretDB/FerretDB 的 GitHub API 快照——文章写作时的 stars、forks、open issues 与最近 push 活动。
8. FerretDB GitHub README——仓库层面的架构说明：MongoDB 客户端对 FerretDB 说话，FerretDB 再把 SQL 发给带 DocumentDB 的 PostgreSQL。
9. FerretDB 公司页《About》——本文题图所用 Peter Farkas 官方肖像的来源页面。
10. Renato Losio，《FerretDB, an Open-Source Alternative to MongoDB, Releases Version 2.0》, InfoQ，2025 年 2 月 10 日——从独立媒体角度总结 v2.0 在性能、复制支持与兼容面上的变化。