企业官网建设流程全解析

• 后端
• 数据库
• 文档数据库

本文以 FastNetMon（电信网络 DDoS 检测厂商）在 2023 年 11 月发布的客户实践为依据，完整还原其团队为何为新的 SaaS 产品 FastNetMon Cloud 选择 FerretDB 作为数据库底座。你将看到一条从 MongoDB 到开源文档数据库的完整决策链路：包括升级与许可痛点、SQLite 与 PostgreSQL 两种后端的选择逻辑、ARM64 平台支持的重要性，以及 FerretDB 社区驱动的发布节奏如何支撑生产级信任。读完本文，你可以把这套评估框架直接套用到自己团队的数据库选型场景中。

背景：一个需要"免维护、高性能、可信赖"数据库的 SaaS 团队

FastNetMon 是面向电信网络的本地部署（on-premise）DDoS 检测方案提供商。为了缩短网络遭受攻击时的产品部署时间，他们正在打造一项名为FastNetMon Cloud的新服务——客户无需部署新硬件、无需安装产品，就能在几分钟内获得流量可见性与攻击检测能力。

云服务形态对底层数据库提出了三个硬性要求，这也正是本文案例的技术主线：

1. 低维护成本：数据库不能成为团队日常运维的负担；
2. 出色的性能：需要支撑实时流量分析与攻击检测；
3. 可信赖的未来：数据库必须有清晰的、可预测的路线图，背后有可靠的团队持续投入。

动机：六年的 MongoDB 使用经验与四个无法回避的痛点

FastNetMon 团队使用 MongoDB 超过六年，积累了大量的运维经验。无模式（schema-less）数据库让开发者可以专注于产品逻辑，不必被数据库相关的琐碎问题分心——这是他们长期停留在这个技术栈的根本原因。

但与此同时，MongoDB 相关的问题恰恰是他们支持工单中最高频的一类。具体痛点集中在四个方面：

其中AVX 强制要求是促使团队开始寻找替代方案的主要原因之一：受此影响，他们只能对部分使用支持 AVX 硬件的客户执行升级。而对于从本地部署走向 SaaS 的 FastNetMon Cloud 来说，SSPL 许可在云环境下的潜在风险也构成了明显的隐忧——尽管本地部署产品不受 SSPL 影响，云产品却必须谨慎评估。

技术选型：为什么选择 SQLite 后端，而不是 PostgreSQL

面对 FerretDB，FastNetMon 团队评估了两条技术路径：

• FerretDB + PostgreSQL：将 PostgreSQL 作为文档数据的存储后端；
• FerretDB + SQLite：以 SQLite 作为存储后端。

最终他们选择了SQLite 方案。决策逻辑非常务实：

因为数据量非常低，我们明确不希望保留 PostgreSQL 守护进程作为额外依赖。

这一选择与 FerretDB v1.x 时代的设计完全吻合。在 FerretDB v1.24 的配置文档（website/versioned_docs/version-v1.24/configuration/flags.md）中，SQLite 后端可以通过--handler=sqlite启动参数或FERRETDB_HANDLER=sqlite环境变量启用，并用--sqlite-url（环境变量FERRETDB_SQLITE_URL，默认值file:data/）指定存储目录：

从源码文档还可以看到更多底层实现细节：v1 时代 FerretDB 使用 modernc.org/sqlite 库访问 SQLite 数据库文件，并自动为未显式设置的 PRAGMA 提供合理默认值——例如auto_vacuum(none)、busy_timeout(10000)、journal_mode(wal)；URI 指向的是一个已存在的目录（而非单个数据库文件），从而支持多数据库工作；内存 SQLite（如file:./?mode=memory）也完全受支持。

需要注意版本前提：FerretDB v2.x 之后的架构已变化。根据迁移文档（website/docs/migration/migrating-from-v1.md），v1.x 同时提供 PostgreSQL 与 SQLite 两种后端选项，而 v2.x要求 PostgreSQL 搭配 DocumentDB 扩展作为后端，以换取更好的兼容性与性能。因此本文中"SQLite 单进程零依赖"的取舍，适用于当时的 v1.x 场景；当前仓库的 README 也确认了 FerretDB 现为"将 MongoDB 5.0+ wire 协议查询转换为 SQL，使用 PostgreSQL 与 DocumentDB 扩展作为数据库引擎"的代理架构（见 README.md）。这正是该案例价值所在——它记录了 FastNetMon 在"数据量小、拒绝额外守护进程"约束下的真实决策过程。

平台策略：Go 语言与 ARM64 支持如何化解硬件锁定

FerretDB 用 Go 语言实现，能够在所有受支持的平台上运行。这一点在 FastNetMon 的云平台成本评估中起到了关键作用：

• 他们为云平台优先选用了ARM64 Graviton 2 与 Graviton 3 CPU；
• FerretDB 在他们提出需求的当天就补上了对应支持；
• 随着FerretDB v1.12发布，官方正式提供linux/arm64 二进制与 .deb/.rpm 软件包，ARM64 支持进入正式发布状态。

团队由此获得了极具价值的平台自由度：没有 AVX 硬件要求，且可以在自己产品覆盖的大部分平台上使用同一份 FerretDB 二进制。

这些陈述在仓库中有完整的版本演进证据链：

• v1.12 发布说明（website/blog/2023-10-11-ferretdb-v112-available.md）明确宣布新增 linux/arm64 二进制与 .deb/.rpm 包，并说明生产 Docker 镜像改用scratch作为基础镜像、镜像中仅包含 FerretDB 二进制（内嵌根 TLS 证书）；
• CHANGELOG.md 记录了后续持续投入，例如 v2.x 阶段"Add full arm64 support"（完整 arm64 支持）与"Use QEMU on arm64 for Yugabyte"等条目；
• v2.2.0 发布说明（website/blog/2025-05-09-ferretdb-v220-arm-architecture-support.md）进一步确认：FerretDB 与 DocumentDB 均已提供完整的arm64架构支持，覆盖 AWS Graviton、Apple Silicon 等 ARM 平台，并保留"全架构兼容"的承诺——这与 FastNetMon 当年的诉求一脉相承。

对于运行在 Graviton 这类 ARM 实例上的 SaaS 平台而言，这意味着计算成本优化与架构统一可以同时实现，而不必为数据库单独保留 x86 节点。

结论：MongoDB 接口兼容 + 低运维成本 + 快速发布节奏

FastNetMon 团队的最终结论是：FerretDB 提供与 MongoDB 接口的完全兼容性，同时具备更简单的维护、快速的发布周期和以社区为中心的发展观——这正是他们选择将 FerretDB 作为 FastNetMon Cloud 平台基础的原因。

对照本文开头提出的三个选型标准：

需要说明的是，"完全兼容"这一表述出自 FastNetMon 团队对自身使用场景的评估。从仓库事实看，FerretDB 的定位是"在多数场景下可作为 MongoDB 5.0+ 的即插即用替代品"，其功能仍在持续扩充以提升兼容性与性能（见 README.md 的 Scope 说明）。企业在选型时仍应结合自身实际使用的查询与命令做兼容性验证。

两个团队

关于 FastNetMon：这是一支深耕网络安全的专业团队，公司 2016 年成立于伦敦，业务遍布全球，致力于保护企业免受网络威胁，其本地部署方案覆盖电信网络的 DDoS 检测场景。

关于 FerretDB：FerretDB 是构建在 PostgreSQL 之上的真正开源 MongoDB 替代品，允许用户无缝地使用 MongoDB 驱动，以 PostgreSQL 作为数据库后端。其使命是让开源社区与开发者享受到易用文档数据库的收益，同时避免供应商锁定与伪开源许可问题。它由 FerretDB Inc. 维护，与 MongoDB Inc. 及其子公司、关联公司没有任何隶属、关联或授权关系。

延伸阅读（仓库内资源）

• 项目定位与快速开始：README.md
• FerretDB v1.12 发布说明（arm64 二进制与软件包）：website/blog/2023-10-11-ferretdb-v112-available.md
• FerretDB v2.2.0 发布说明（完整 ARM64 架构支持）：website/blog/2025-05-09-ferretdb-v220-arm-architecture-support.md
• v1.x SQLite 后端配置说明：website/versioned_docs/version-v1.24/configuration/flags.md
• 当前版本配置参数（PostgreSQL 后端）：website/docs/configuration/flags.md
• 从 v1.x 迁移到 v2.x 的差异说明：website/docs/migration/migrating-from-v1.md

• 后端
• 数据库
• 文档数据库