使用 AWS RDS PostgreSQL 作为主数据库

我们正在构建一个多租户 SaaS 产品（B2B 运营平台），当前 MVP 阶段使用单体 PostgreSQL 自建实例。随着以下变化，主数据库选型需要做出正式决策：

• 业务复杂度持续增长 — 核心领域模型涉及用户/租户/订单/订阅/审计等 8+ 聚合根，跨表 JOIN 查询频繁（平均每条业务请求触发 3–7 个 JOIN）；
• 数据一致性要求高 — 计费、订阅状态变更、租户配额扣减均要求 ACID 事务，不允许最终一致性窗口；
• 即将进入规模化阶段 — 预计未来 12 个月租户数从 20 增长至 500+，数据库写入 QPS 从 200 增长至 ~2,000；
• 运维资源有限 — 团队 5 名后端工程师，PostgreSQL 经验 3+ 年，MongoDB 运维经验为零；无专职 DBA；
• 合规需求 — 需支持 SOC 2 Type II 审计，要求所有数据变更可追溯（行级审计日志）。

我们需要在 PostgreSQL / MongoDB / MySQL 三者中选择一个作为主数据库，并在 2 周 deliberation 内完成决策。

决策理由：

• 关系模型匹配业务 — 8+ 聚合根、频繁 JOIN、ACID 事务是典型的关系型负载，PostgreSQL 在此场景下性能与正确性均优于文档数据库；
• 团队能力匹配 — 全团队 PostgreSQL 3+ 年生产经验，能独立完成 schema 设计、查询优化、备份恢复，MongoDB 从零学习 + 试错成本估计 6–8 周；
• 托管服务降运维负担 — AWS RDS 提供自动备份（Point-in-Time Recovery）、自动补丁、Multi-AZ 故障切换、存储自动扩容，将运维负担从「自建需 1 人全职」降至「0.2 人兼职」；
• 生态成熟 — pgAudit（审计日志）、pg_stat_statements（慢查询）、PostGIS（未来可能地理位置需求）、TimescaleDB（时序指标）均可零成本接入；
• 可逆性可控 — 使用标准 ANSI SQL + pg_dump 导出，迁移至 MySQL 或 CockroachDB 的成本在可控范围内（见 §5 可逆性评估）。

✅ 正面后果

• 团队零学习成本，上线速度最快 — 现有 schema migration 工具链（Flyway + SQL）直接复用；
• AWS RDS 自动运维（备份/补丁/故障转移），运维人力节省约 0.8 FTE；
• ACID + SERIALIZABLE 隔离级别满足计费/订阅场景的强一致性要求；
• pgAudit 原生支持 SOC 2 行级审计日志，无需额外中间件；
• PostgreSQL 扩展生态（PostGIS / pgvector / TimescaleDB）为未来需求预留空间。

⚠️ 负面后果

• 水平扩展（sharding）不如 MongoDB 原生支持成熟 — 若未来写入 QPS 突破 10,000，需要引入 Citus 或应用层分片，增加架构复杂度；
• Schema 变更需要显式 migration（Flyway），无法像 MongoDB 那样无 schema 快速迭代字段；
• AWS RDS Multi-AZ 费用约 $0.50–0.80/小时（db.r6g.xlarge），年度成本约 $4,500–7,000，高于自建但低于 MongoDB Atlas 同级实例；
• JSON 查询能力（jsonb 类型）虽成熟，但在深度嵌套文档的频繁部分更新场景下性能不及 MongoDB 原生 BSON。

⚪ 中性后果

• 团队需要在 3 个月内完成从自建 PostgreSQL 到 AWS RDS 的迁移（预计 2 周 downtime 窗口）；
• ORM（Prisma）同时支持 PostgreSQL 与 MySQL，切换无代码层障碍，但 MongoDB 需换用 Mongoose 或 Prisma MongoDB connector。

MongoDB 未被选择的原因：

• 业务核心负载是关系型查询（JOIN / 子查询 / 聚合），MongoDB 的文档模型在数据一致性、跨集合查询和 ACID 多文档事务方面是反模式；
• 团队零运维经验 → 生产事故风险不可接受（若 replica set 脑裂、oplog 溢出无法自主排障）；
• SSPL 许可证对 SaaS 场景有法律不确定性。

MySQL 未被选择的原因：

• PostgreSQL 在所有 5 个维度上均等于或优于 MySQL，已知团队 Postgres 经验更深；
• MySQL 的 JSON 函数、CTE（8.0 才支持）、部分索引等特性弱于 PostgreSQL，未来业务复杂度可能被迫绕过；
• PostgreSQL 扩展生态（pgAudit / pgvector / TimescaleDB）对应明确的近期需求，MySQL 无等价能力。