MongoDB 与 PostgreSQL：2026 年如何选择合适的数据库

如何看待这项比较

当工作负载主要是关系、约束、事务和灵活报表时，选择 PostgreSQL。当大多数操作读取或更新边界明确、自包含且字段差异很大的文档时，选择 MongoDB。没有哪个引擎在所有情况下都更快或更简单。

从应用本身开始，而不是从功能清单开始。计费系统与内容目录的失败条件不同，即使两者都通过 API 提供 JSON。数据库应让应用最困难的操作变得日常可做，而不只是勉强可行。

用五个具体问题评估两种选择：

• 哪些记录必须在同一事务中一起变更？
• 哪些查询会跨越实体边界，它们变化得有多频繁？
• 即使应用代码出错，哪些规则也必须保持成立？
• 一条逻辑记录最多会有多大，它的子集合会不会无限增长？
• 谁负责运行、恢复和调优数据库，并响应故障？

对于 SaaS 账户、权限、订单、计费、库存、审计轨迹、CRM 和 ERP，PostgreSQL 通常是风险更低的默认选择。这些领域包含多对多关系和不变量，适合表、外键、唯一约束和 SQL。

MongoDB 常适合内容条目、带租户专属属性的产品记录、配置文档、事件载荷，以及通常以单个对象取回的其他聚合。灵活的文档结构能缩短首次实现时间，但团队仍需控制架构演进。

当两种数据库各自负责清晰分隔的领域时，同时使用它们是合理的。边界模糊时成本很高。两个存储意味着两套备份系统、两种监控模型、两套安全配置和一套同步机制。只有当单一数据库会持续造成建模或扩展问题时，才值得承担这些成本。

数据模型：文档还是关系表

MongoDB 适合能保存为有界聚合的数据，PostgreSQL 适合价值取决于可独立变化实体之间关系的数据。区别不止是 JSON 与行，它决定了一致性规则放在哪里。

一个 MongoDB 订单可能嵌入收货地址和明细项：

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

一次有索引的查询就能返回完整订单。一次更新也能原子地修改订单及其嵌入项。当这些部分共享生命周期且数组保持有界时，这很有吸引力。

对应的 PostgreSQL 模型会拆分具有独立意义的事实：

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

这个模型让跨订单报表和产品关系更直接。数据库可拒绝订单或产品不存在的明细项。产品也能独立变更，同时保留购买时记录的价格。

对于账户产生的全部事件这类无限集合，嵌入并不合适。持续增长的文档会形成写入热点、消耗更多带宽，最终碰到 MongoDB 的 16 MiB 文档限制。应将这些事件存为独立文档。

规范化也可能做得过头。把一个小型值对象拆到多张表中，会增加联结却没有带来有用的独立性。已完成订单中记录的收货地址通常是历史快照，不是指向客户当前地址的实时引用。

一条持久的建模原则是：嵌入会一起变化且保持有界的数据。对独立变化、参与许多关系或无法预估上限的数据，使用引用或规范化。

架构演进与数据完整性

MongoDB 更容易添加字段，PostgreSQL 更容易强制统一结构。无论使用哪个系统，生产安全都依赖严谨的迁移。

MongoDB 集合可包含字段和类型不同的文档。这种灵活性有利于随租户或内容类型变化的属性，但也可能产生同一概念的多个不兼容版本。字段改名后旧文档可能仍在，每个读取方都需要回退逻辑。

MongoDB 支持 JSON Schema 风格的集合验证。团队可逐步引入验证、回填现有文档，再拒绝不符合选定结构的新写入。架构版本字段能帮助工作程序有序迁移旧文档，但不能取代验证。

PostgreSQL 的变更是显式的。团队通常先添加可为空的列，必要时部署同时写入旧、新格式的代码，分批受控回填，验证数据，最后增加更严格的约束。大型索引可并发构建以减少对写入的影响。外键和部分约束也可分阶段引入，再进行完整验证。

引擎能表达的有用不变量应放在数据库中：

• 对标识符、幂等令牌和每个所有者仅一条的记录使用唯一约束。
• 对绝不能指向缺失数据的关系使用外键。
• 对正数量等局部规则使用 CHECK 约束。
• 对需要远程服务或频繁变化政策的上下文规则使用应用验证。
• 用测试验证从每个受支持架构版本迁移的路径。

应用验证仍然需要，它能提供友好的错误信息并支持业务流程。数据库约束是防范竞争、遗漏代码路径、管理脚本和未来写入同一数据服务的最后屏障。

灵活架构应意味着受控的变化，而不是未知的变化。在为加快迭代而选择 MongoDB 前，要明确谁负责文档结构、如何发现不兼容变更、何时重写旧文档。

查询、联结与报表

PostgreSQL 更直接地应对不断变化的跨实体问题，MongoDB 则在查询遵循单个文档边界时更简洁。随着产品积累报表需求，查询易用性会越来越重要。

SQL 是声明式语言。筛选、联结、分组、公共表表达式、窗口函数、子查询和集合操作可以组合使用，无需改变存储模型。PostgreSQL 的规划器根据统计信息和可用索引选择联结算法与访问路径。

跨规范化订单数据的收入查询依然清晰：

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB 对简单读取使用直接查找，对转换使用聚合管道。使用嵌入明细项时，对应计算会按顺序经过多个阶段：

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

管道功能强大，但阶段顺序会影响含义和资源消耗。大型数组经过 $unwind 后可能成倍扩大工作集。尽早筛选和投影可降低成本。

MongoDB 的 $lookup 可从另一个集合联结文档。它适合选定关系，尤其在被联结一侧有索引且结果较小时。如果常见请求需要多个 $lookup 阶段，往往说明模型边界可能更适合关系型设计。

PostgreSQL 通常更适合商业智能、财务报表、队列分析和未预先设计的问题，因为大多数报表工具都使用 SQL。当维度已放在一起，或预先准备的读模型正好匹配报表时，MongoDB 报表也能很好地工作。即使主数据库不是关系型，频繁进行临时分析的团队也常将业务数据导出到数仓。

对象映射不会消除这些取舍。ORM 能让 PostgreSQL 的行看起来像对象，对象文档映射器可在 MongoDB 文档上施加类。负载下的行为仍由存储关系、索引和完整性规则决定。

事务与并发

PostgreSQL 为多行、多表事务提供最自然的模型，MongoDB 为单文档变更提供成本最低的原子边界，并在需要时支持更广泛的事务。正确选择取决于必须在并发请求下保持的不变量。

PostgreSQL 使用多版本并发控制。普通读取和写入可并发进行，但行锁、显式锁、长事务和架构变更仍可能导致等待。默认隔离级别是 Read Committed。Repeatable Read 提供稳定的事务快照，Serializable 会检测无法安全排序的执行。

MongoDB 修改单个文档的操作是原子的。因此嵌入有界聚合能减少协调。MongoDB 也在副本集和分片集群中支持 ACID 多文档事务。这些事务会增加协调、在持续期间占用资源，并可能产生临时错误，应用需要重试完整事务。

MongoDB 分别提供读关注、写关注和读偏好。这些设置会影响读取可看到的数据、多少副本集成员必须确认写入，以及读取是否可转到辅助节点。应先把它们视为正确性设置，再把它们当作延迟控制手段。

两种数据库都无法将外部支付服务商纳入本地数据库事务。在发起网络请求时一直保持事务打开，会增加竞争，却仍不能让两个系统原子提交。更安全的支付流程是在一次数据库事务中记录待处理订单和 outbox 事件，以幂等方式处理外部请求，再记录结果。

并发测试应针对业务竞争，而不只验证成功请求。例如，两名买家预订最后一件商品、两个工作程序领取同一任务，或两名管理员分配同一个唯一名称。PostgreSQL 往往可用约束、行锁或原子语句表达这些操作。MongoDB 可用条件更新、唯一索引和事务。

若严格规则跨越大量独立存储的记录，PostgreSQL 通常需要更少的应用协调。若每条规则都能装入精心设计的单个文档，MongoDB 的原子文档操作既简单又有效。

PostgreSQL JSONB：中间路线

当一组稳定的关系字段围绕有限的演进属性时，PostgreSQL JSONB 是很好的选择。它不能把所有文档形问题都变成关系型问题，但可免去第二个数据库。

常见设计会将身份、归属、状态和时间戳放在强类型列中，可选属性放在 jsonb 中。外键保护关系，普通索引支持高频筛选，GIN 或表达式索引加速选定 JSON 谓词。

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

这适合材料、尺寸或区域元数据等产品类型间不同的目录属性。如果每个重要字段都埋在 JSON 中，每次查询都需要类型转换、路径表达式或自定义验证，它就不太合适。

JSONB 保存已解析的二进制表示，支持包含操作符，并会舍弃对象属性顺序等无关格式。对于重复的对象属性，它只保留一个值。必须原样重现原始 JSON 文本的应用，应另行保存该文本。

更新一个小属性会创建新的 PostgreSQL 行版本，并可能重写较大的 JSONB 值。因此，大型且频繁更新的文档可能产生大量预写日志和死元组。将热点字段拆为列或子表通常性能更好。

外键无法直接约束藏在任意 JSON 内的关系。将经常查询、联结、排序或受约束的值提升为列。生成列和表达式索引可帮助逐步过渡，但字段含义稳定后，关系型字段通常更清楚。

索引与查询计划

两种数据库都依赖能匹配真实筛选、排序和基数的索引。盲目加索引会拖慢写入并消耗内存。它们的索引工具不同，但没有一种能挽救与存储模型相冲突的访问模式。

PostgreSQL 用 B-tree 索引支持等值、范围和有序读取。GIN 索引支持 JSONB 包含、数组和全文检索。GiST 与 SP-GiST 覆盖多种几何、范围和专用操作符类。BRIN 对物理顺序与时间等值相关的超大表来说是紧凑选择。

PostgreSQL 还支持部分索引和表达式索引。活动订阅的部分索引可能远小于覆盖多年失效记录的索引。表达式索引可支持规范化邮箱地址或选定 JSON 属性。

MongoDB 可直接为嵌套属性和数组建立索引。多键索引会将数组值扩展为索引条目，成员查询高效，但索引可能迅速膨胀。复合多键索引不能同时为同一文档中两个数组值字段建索引。MongoDB 还提供地理空间、哈希、通配符、部分、稀疏和 TTL 索引选项。

复合索引中的列顺序应遵循查询结构，而不是通用的“最具选择性优先”规则。PostgreSQL 多列 B-tree 中，前导列的等值条件加上下一列的范围条件通常能高效扫描。MongoDB 实践中常先放等值字段、排序字段，再放范围字段，同时检查针对真实数据分布的其他顺序是否扫描更少条目。

使用查询计划，而非猜测：

• 在 PostgreSQL 中，对代表性读取执行 EXPLAIN (ANALYZE, BUFFERS)，检查行数估计、循环、排序、磁盘溢出和缓冲区活动。
• 注意 ANALYZE 会实际执行语句，因此要谨慎处理写入和生产流量。
• 在 MongoDB 中，请求执行统计信息，比较检查的文档数、索引条目数和返回结果数。
• 测试常见参数值，也测试覆盖大量数据的偏斜值。
• 只有确认索引未被周期性、管理和故障切换工作负载使用后，才移除未使用索引。

一个索引可能完美覆盖某个端点，却与另一索引重复，或增加每次写入的成本。应将完整索引集合视为一个组合来审查，而不是独立批准每个索引。

搜索、地理空间与时序工作负载

两种数据库都能覆盖基础搜索、位置和时间查询，但专业产品需求可能需要独立工具或托管功能。决策应取决于相关性质量、写入速率、保留期和运维责任。

PostgreSQL 全文搜索提供分词、词典、加权文档向量、查询操作符、排序和 GIN 加速。当语料和相关性规则仍可控时，它很适合应用内搜索。三元组索引可为名称或标识符提供相似度和子串匹配。

MongoDB 文本索引可处理基础词语搜索。MongoDB 的托管平台还提供独立搜索和向量搜索能力，用于更丰富的相关性和检索工作负载。比较可移植性、定价、备份行为和本地开发时，应将其视为依赖部署的服务。

向量搜索改变的是查询类型，而不是对事务型事实来源的需求。PostgreSQL 可通过扩展添加向量索引，MongoDB 部署可将业务文档与支持的向量搜索服务配合使用。应使用应用自身的嵌入向量评估召回率、筛选、索引构建时间、更新可见性和成本。

地理空间工作中，PostgreSQL 常用 PostGIS 扩展处理高级几何、坐标系和空间分析。MongoDB 提供适合位置感知应用查询的地理空间索引和操作符。列出实际操作后再选择较简单方案，因为查找附近点的要求远低于修复多边形或复杂空间联结。

MongoDB 时序集合将测量值组织进内部桶，并支持按时间过期。PostgreSQL 可通过分区、BRIN 索引和可选扩展处理时序数据。超高量遥测在写入后仍可能应进入专用分析存储，特别是长期保留和大范围扫描比事务更新更重要时。

性能与代表性基准

数据布局、索引覆盖、工作集大小和持久性设置通常比通用 MongoDB 与 PostgreSQL 基准结果更重要。可信测试会复现应用的数据分布和并发情况。

当一次请求映射到一个有索引的文档时，MongoDB 可提供低延迟读取。文档很大、响应只需少量分散字段，或关系需要反复查找时，这一优势会缩小。嵌入数组也会增加索引条目数，并让更新越来越昂贵。

当统计信息准确、联结列有索引时，PostgreSQL 可高效执行复杂联结。查询产生大型中间结果、排序或哈希溢出到磁盘，或反复获取许多无关页面时，性能会下降。只选择所需列并纠正数据模型问题，通常比改写 SQL 语法更重要。

两种系统中，每个二级索引都会增加写入工作。大型 JSONB 值、宽行、超大文档和重复的反规范化数据都会增加 I/O。即使单条查询很快，连接风暴也可能耗尽资源，因此应使用有上限的连接池，并在故障切换时测试重连行为。

有用的基准应保留这些条件：

• 加载足够数据，反映预期工作集与可用内存的比例。
• 匹配生产环境的一致性、日志、复制和确认设置。
• 按真实读写比例回放最主要的应用操作。
• 包含偏斜、热点租户、大账户、缺失记录和最坏筛选条件。
• 在稳定负载和恢复事件中记录吞吐量以及 p50、p95 和 p99 延迟。

每次只做一项受控变更。在硬件和请求语义不变的情况下，比较规范化表与 JSONB、嵌入文档与引用，或不同索引。热缓存微基准无法预测备份压力、复制延迟、检查点行为或主节点故障后的性能。

容量规划应包括数据和索引的增长。上线时能放入内存的索引，一年后可能主导延迟。应使用预测的数据量重复测试，而不是从空数据库外推。

水平扩展与数据分布

MongoDB 提供集成分片来分散写入，PostgreSQL 通常先结合纵向扩展、分区和副本，再采用独立的分布式架构。水平扩展会带来影响每个查询的路由和归属决策。

MongoDB 分片集群根据分片键分发文档。好的分片键应有足够基数，避免持续将写入集中到某处，支持常用路由谓词，并均匀分配存储。未包含分片键的查询可能访问每个分片，从而增加延迟和资源消耗。

哈希分片可更均匀地分布顺序标识符，但会削弱范围局部性。范围分片支持定向区间，却可能在范围末端形成热点。区域可将选定范围放到指定分片，以满足租户或地理规则。重新分片能纠正不佳选择，但移动大型在线数据集仍需要规划和冗余容量。

MongoDB 事务可跨分片，但跨分片协调成本高于路由到单一分片的操作。应用若将租户标识符同时放入分片键和常用查询中，往往可让相关工作保持在本地。

PostgreSQL 原生分区将逻辑表拆成子表，通常按时间、租户或其他路由值划分。分区裁剪可减少扫描，分区也能简化保留操作。原生分区本身不会将写入分散到多台机器，因此不应称为分片。

PostgreSQL 只读副本可将适合的读取流量从主库移走。副本不会增加主库写入能力，异步副本也可能返回较旧数据。应用必须决定哪些读取可容忍这种延迟。

当单个 PostgreSQL 写入节点不再足够时，团队可在应用代码中分片、采用分布式 PostgreSQL 扩展或服务，或将领域拆成独立数据库。每种选择都会改变跨分片联结、唯一性、序列和事务的行为。在应用依赖全局操作前，应测试这些限制。

扩展需求应量化说明。预期每秒写操作数、数据集大小、热点租户集中度、区域位置和恢复目标，比笼统要求水平扩展更有用。

复制、故障切换与恢复

两种数据库都可提供高可用性，但恢复行为取决于拓扑、确认策略、自动化和反复测试。仅靠复制并不能保证停机时间短或零数据丢失。

MongoDB 通常以副本集运行，包含一个主节点和多个辅助节点。当前主节点不可用时，成员会选举新主节点。应用应使用受支持的驱动程序，配置服务器选择和操作超时，并处理临时错误。可重试写入有助于部分操作，但重试仍须遵守应用的幂等性。

写关注控制多少成员确认写入。读偏好决定符合条件的读取是否使用主节点或辅助节点，读关注控制可见性保障。低延迟配置可能暴露更多故障或陈旧数据风险，因此应记录每种工作负载选择的组合。

PostgreSQL 物理流复制将预写日志记录从主节点发送到备用节点。异步复制保护可用性和延迟，但如果备用节点在收到日志前主节点已毁坏，最近确认的事务可能丢失。同步复制可降低这一风险，但会增加提交延迟并更依赖备用节点健康状态。

PostgreSQL 故障切换通常由托管服务或外部自动化协调。流程必须提升合适的备用节点、重定向客户端，并阻止旧主节点接受冲突写入。连接池和 DNS 缓存可能在提升后延长可见停机时间。

备份可防范复制会忠实复制的故障，包括误删和逻辑损坏。PostgreSQL 的基础备份加归档预写日志可实现时间点恢复。MongoDB 部署可借助合适工具或托管服务使用协调快照和基于 oplog 的恢复。

分别定义恢复点目标和恢复时间目标。然后在隔离环境中测试完整恢复，验证应用数据，轮换恢复后的凭据，并记录耗时。快照成功并不证明完整服务能在目标时间内恢复。

运维维护

PostgreSQL 和 MongoDB 需要不同的例行维护，团队经验可能比小的功能优势更重要。托管服务能减少部分工作，却不会替你负责查询设计、容量决策或恢复验证。

PostgreSQL 会在事务更新和删除数据时产生过时的行版本。自动清理会回收可复用空间、更新可见性信息并防止事务 ID 耗尽。长事务可能延迟清理。应监控死元组、表和索引增长、清理进度、事务年龄，以及保持旧快照存活的查询。

规划器统计信息也需关注。偏斜值或相关列可能导致行数估计不准和差计划。提高统计目标或创建扩展统计信息可帮助特定查询。性能审查应在数据大幅增长后进行，而不只在代码变更后进行。

MongoDB 的 WiredTiger 存储引擎高度依赖缓存和压缩。应监控缓存压力、磁盘延迟、文档增长、检查点行为、复制延迟，以及检查文档数与返回文档数的比例。分片部署中，还应关注均衡活动、分块分布不均和散布到多个分片的操作。

日常运行手册应覆盖五个方面：

• 慢查询采集、负责人和处置阈值。
• 基于增长速度而非仅当前占用率的容量告警。
• 记录恢复时间和验证步骤的恢复演练。
• 凭据轮换和紧急访问流程。
• 针对驱动、扩展、索引和回滚计划测试过的版本升级。

PostgreSQL 大版本升级通常使用 pg_upgrade、逻辑复制或托管迁移流程。扩展兼容性可能决定可行路径。MongoDB 升级遵循受支持版本序列和 Feature Compatibility Version 控制，分片集群需谨慎安排组件顺序。

pg_dump 和 mongodump 等逻辑导出工具适合较小数据集和选择性恢复。大规模下，它们可能无法满足严格恢复目标。在将其作为主要灾难恢复方法前，应以生产规模数据测量导出和导入时长。

安全与治理

只要明确设计访问、加密、审计和网络控制，两种数据库都能满足严格安全要求。默认凭据或私有网络本身无法形成可审计系统。

PostgreSQL 角色可在数据库、模式、表、序列、函数和列级别获得权限。视图可暴露选定字段，行级安全可按用户或租户上下文限制行。应将对象所有权与普通应用角色分开，避免被攻破的服务修改自身限制。

MongoDB 角色可授予数据库、集合和集群资源上的操作。应用读取、应用写入、迁移、监控、备份和管理应使用独立身份。避免在服务间共享一个权限过大的凭据。

一套实用控制措施包括：

• 对客户端和复制流量强制使用 TLS，并在每个驱动中验证证书处理。
• 在托管机密系统中保存密钥，并可不经完整应用发布完成轮换。
• 限制网络路径，避免将数据库监听器直接暴露到公网。
• 记录策略要求的身份验证、权限、架构和敏感数据访问事件。
• 测试分析人员、支持人员和自动化账户无法超越其职责范围。

静态加密可能结合数据库能力、加密存储和云托管密钥。MongoDB 在受支持部署中也支持客户端字段级加密。若数据库管理员不应看到明文，PostgreSQL 应用通常会在存储前加密选定值。加密会改变索引和查询选项，因此应先原型化受保护操作。

治理还需要数据分类、保留、删除、驻留和事件响应流程。区域部署可支持驻留目标，但合规还取决于备份、日志、支持访问、分处理方，以及所有接收数据的系统。

成本、许可与总体拥有成本

更便宜的数据库，是能以可接受的基础设施、服务费用和工程投入满足工作负载的那个。许可证价格很少单独决定总体拥有成本。

复杂查询、压缩工作、索引维护、后台任务和复制都会提高计算成本。存储包括索引、保留日志、备份、临时空间和反规范化引入的重复数据。即使不计快照和跨区域传输，三个承载数据的副本也会保存多份数据。

PostgreSQL 使用宽松的 PostgreSQL License，可通过许多自托管和托管发行版获得。商业支持和云服务可按需购买。扩展可能有自己的许可证，应单独审查。

MongoDB Community Server 使用 Server Side Public License，它源码可用，但未经 Open Source Initiative 批准。MongoDB Atlas 和商业支持采用供应商定价与条款。嵌入数据库功能或将其作为服务提供的组织，应让法律顾问审查适用条款，不能假定其等同于宽松开源许可证。

托管数据库以更高单价交换自动配置、修补、备份、监控集成和部分故障切换流程。架构质量、慢查询、连接管理、数据分类和应用恢复仍由客户负责。

估算总体拥有成本时考虑：

• 生产、预发布、开发、灾备和临时环境数量。
• 至少未来 12 到 24 个月的数据和索引增长。
• 所需副本、区域、备份保留期和网络传输。
• 峰值吞吐量、工作集内存和配置的存储性能。
• 迁移、调优、事件响应、审计和恢复演练所需的人力时间。

团队已熟练支持的数据库，可能比技术上吸引人的替代方案更便宜。培训、新自动化、修改值班流程和迁移风险都是真实成本。

按工作负载匹配应用

PostgreSQL 是关系密集型记录系统的更强默认选择，MongoDB 则适合具有独立归属和可变文档的领域。具体工作流比“Web 应用”或“企业系统”等宽泛标签更能揭示匹配度。

SaaS 账户模型通常包含组织、成员关系、邀请、角色、订阅、发票、权益和审计记录。唯一性与跨实体规则至关重要，管理员最终会提出上线时未预料的报表需求。PostgreSQL 很适合这种模式。

产品目录可能为服装、电子产品、工业零件和自定义租户类别包含不同属性集。MongoDB 可把每件产品存成连贯文档，而不必创建稀疏的通用表。当产品还深度参与定价表、库存事务、供应商协议和关系报表时，使用 JSONB 的 PostgreSQL 仍很有竞争力。

内容管理领域常自然映射为包含区块、本地化、元数据和发布状态的文档。每个条目作为整体读取和修订时，MongoDB 表现很好。若编辑权限、排期、跨内容引用和报表比文档变化更复杂，PostgreSQL 可能更合适。

财务总账、库存预留和计费记录更适合 PostgreSQL。仅采用追加式设计，仍无法消除对唯一性、平衡分录、对账查询和多记录不变量的需求。

事件和遥测系统需要更细致的测试。MongoDB 可写入文档式事件，PostgreSQL 可分区处理高追加量的表。持续分析规模很大时，业务数据库可能会向列式数仓或专用时序系统供数。保留期、聚合窗口、迟到数据和查询扫描大小应决定存储路径。

当权威实体留在 PostgreSQL，而文档领域拥有独立归属和访问模式时，混合架构才合理。为每个实体指定唯一事实来源。通过 outbox 或变更数据捕获发布变更，使用幂等消费者，并为延迟或重复投递做好规划。避免同步双写，因为部分失败后可能让两个存储不一致。

实用决策方法

对于接近的 MongoDB 与 PostgreSQL 选择，使用生产形态数据做一个短期概念验证，是最可靠的决策方式。测试应集中在困难部分，而不是通用的增删改查演示。

选择三个代表性工作流：最常见请求、最复杂查询和正确性要求最严格的操作。在两种数据库中如实建模每个工作流。不要强迫 PostgreSQL 用一列无限制 JSON 模仿文档库，也不要强迫 MongoDB 在许多集合中复制高度规范化的架构。

根据模型清晰度、正确性、查询成本、实测延迟、运维熟悉度、恢复、安全控制和预测成本为候选方案评分。在看到基准结果前先设定各类别权重。金融应用应比避免迁移更重视完整性和可审计性，可丢弃的内容原型则可能相反。

如果设计依赖以下任一假设，就应拒绝：

• 每个未来查询都会遵循第一个 API 的访问模式。
• 应用验证会永远在每条写入路径上正确执行。
• 一个超大租户会和中位数租户表现相同。
• 复制消除了对备份和恢复演练的需求。
• 第二个数据库的运维成本很低，只因首次部署使用托管服务。

对于通用事务型应用，PostgreSQL 仍是更稳妥的起点。它的表、SQL、约束、成熟事务模型和 JSONB 支持，为结构化数据和选定半结构化数据都留出了空间。MongoDB 应因文档模型带来明显更简单的设计，或其集成分布模型符合实测需求而胜出，而不是因为迁移看起来麻烦。

将选择用于 Koder.ai 项目

PostgreSQL 是大多数 Koder.ai 项目的自然起点，因为平台主栈使用 React、Go、PostgreSQL 和 Flutter 来构建移动应用。这个默认选择适合通过聊天界面常创建的网站、CRM、ERP、移动应用和其他事务型系统。

规划模式应在开始生成前识别实体、关系、唯一性规则、数据保留和高量操作。稳定属性应放入强类型列中。真正结构可变的可选业务属性可使用 JSONB。

Koder.ai 支持导出源代码、部署和托管、自定义域名、快照与回滚。快照和应用回滚应补充数据库迁移规划，而不能取代它。架构不兼容变更后回退应用代码，旧代码可能无法读取新写入的数据。

对于生成的 Go 服务，应将数据库变更保存在经过审查的迁移中，并让部署在过渡期内保持安全。常见顺序是添加兼容架构，部署同时理解两种状态的代码，回填数据，切换读取，然后在后续版本中移除过时形式。

Koder.ai 可在不同国家的 AWS 基础设施上运行应用，以支持数据部署要求。数据库设计也必须把这一决定扩展到副本、备份、日志、分析导出和管理访问。地理部署只是更广泛的隐私和治理计划中的一项控制措施。

向基于 PostgreSQL 的项目添加 MongoDB 时，应采用与任何架构依赖相同的标准：在实现前定义文档归属领域、故障处理、同步路径、备份策略和运维责任。

迁移与采用清单

当团队能证明数据完整、应用兼容并且切换可恢复时，数据库迁移才算成功。转换语法只是工作的一部分。

先盘点表或集合、数据量、索引、约束、查询模式、保留规则和每个写入方。识别无法直接转换的语义，例如关系外键变成引用、嵌入数组变成子表、数值精度差异、大小写敏感比较或时间戳处理。

在迁移生产数据前建立核对查询。仅比较数量并不够。按租户和日期比较总额，验证唯一性，抽样大型记录，检查孤立关系，并在适用时计算业务层余额。

受控迁移通常包括以下阶段：

• 进行首次全量复制，并记录被拒绝或转换的记录。
• 通过日志、outbox 或变更数据捕获机制捕捉后续变更。
• 执行影子读取，或比较抽样响应而不改变用户可见行为。
• 通过可逆的路由变更完成切换，同时监控错误和延迟。
• 在核对完成且回滚窗口结束前，将旧存储保持为只读。

除非两次写入都具备幂等性且已明确协调部分失败，否则从应用代码双写风险很高。更好的做法是使用一个已提交的事实来源，加上一条可重试的异步投递记录。

切换后，应重建运维基线。旧引擎的查询计划、连接池大小、告警阈值、备份时长和容量预测不会自动转移。只有新数据库通过恢复演练，并且团队能在故障中运行它，迁移才算完成。