PostgreSQL还是MongoDB：灵活Schema不保证更快写入

为新项目选数据库，如果订单、账户等实体需要长期保持引用和唯一性，PostgreSQL 通常是更直接的起点；如果数据主要作为完整文档读取和修改，MongoDB 值得优先评估。写入性能不能从关系型或文档型的标签推断，还要看查询方式、事务范围、索引和并发负载。

灵活 Schema 的直接收益是容纳不同结构，减少字段变化带来的建模摩擦，并不保证更低的写入延迟。MongoDB 的官方对比说明，同一集合中的文档可以拥有不同字段，MongoDB 也支持二级索引和 ACID 事务；这些能力让文档模型适用于更多场景，但仍需设计记录边界和一致性规则。

先看哪些关系必须由数据库维护

当多个独立实体之间的关系本身就是业务规则，关系模型的价值更明确。PostgreSQL 的约束文档列出主键、唯一约束、检查约束和外键，其中外键能要求引用值对应另一张表中实际存在的记录。商品、订单与账户若分别更新，却始终需要保持有效关联，把规则交给数据库可以让不同写入路径接受同一套校验。

文档模型适合边界清楚的聚合：一份记录中的属性通常一起读取，也随着同一业务动作修改。以一个假设的商品目录为例，不同品类各有属性时，文档可以只保存当前商品需要的字段。若价格、库存和商品资料分别由不同流程维护，并被许多记录引用，把它们反复嵌入文档就可能增加同步工作。

查询模式会改变这种取舍。主要按标识取回完整对象时，文档与访问单位较为一致；经常按多个实体的关系筛选、汇总或重组结果时，关系模型通常更便于表达关联和约束。两种数据库都能处理超出各自典型模型的查询，因此应以日常请求为依据，而不是只看产品类别。

可变字段不一定需要迁移到 MongoDB

核心关系稳定、附加属性多变时，可以先评估 PostgreSQL 的 jsonb。PostgreSQL 的 JSON 类型文档说明，jsonb 支持索引，写入时需要将输入转换为二进制形式，而更新所在行中的 JSON 值会取得整行的行级锁。这些特性意味着字段灵活性、读取便利性和并发更新成本需要分别衡量。

一种混合设计是把身份、状态和需要约束的关联保存在普通列中，将差异较大的附加属性放入 jsonb。这样可以保留清晰的核心关系，同时容纳变化的字段；但频繁用于过滤或排序的属性仍要考虑索引。把所有内容放入一个 JSON 值，只是把部分结构决策转移到了查询和校验阶段。

记录的更新边界也重要。如果许多事务经常修改同一行里的不同属性，整行锁可能造成争用；拆分可独立变化的数据，往往比扩大单条记录更符合实际写入方式。反过来，确实需要一起读取和修改的属性，集中保存可能让应用逻辑更简单。

事务能力之外，还要确定事务边界

两种数据库都能执行 ACID 事务，关键是一次业务动作究竟涉及哪些记录。若修改始终局限于一个完整文档，文档边界与操作边界可以自然重合；若一次提交必须同时改变账户、订单和库存等独立对象，就需要明确哪些变化必须共同成功或回滚。

事务提供提交机制，却不会替应用决定对象如何拆分。关系模型中的外键和唯一约束适合表达长期成立的规则，但热点行和较长的事务也可能增加等待；文档模型可以减少某些跨记录操作，却不宜为了回避事务而复制本该统一维护的数据。选型时应列出实际写入动作触及的记录，以及失败后业务允许保留的状态。

高并发测试说明什么

一项云端 OLTP 基准研究使用 Aiven 上的 PostgreSQL 16.2 与 Atlas 上的 MongoDB 7.0，在文档型负载中比较两套托管服务配置：读取占 95%、写入占 5% 且有 960 个虚拟用户时，MongoDB 写入操作的平均延迟比 PostgreSQL 高约 250 毫秒，各场景结果取三轮独立测试的平均值；研究还采用 PostgreSQL JSONB，并为 MongoDB 写入设置多数节点确认。这个差值属于上述配置与负载，不能直接套用到其他部署。

吞吐量和单次写入延迟回答的是不同问题：前者描述一段时间完成多少操作，后者描述请求等待多久。数据库版本、文档大小、索引、热点键、连接方式、网络位置及确认级别改变时，排序都可能改变。因此，灵活 Schema 是否方便建模，可以先由数据形态判断；哪种方案满足性能要求，则要用接近业务的数据和请求进行压测。

准备迁移时，应让候选方案承担相近的一致性与持久性要求，再分别设定吞吐量、平均延迟和尾部延迟的验收目标。若问题集中在少数热点记录、过大的 JSON 值或不合适的索引，先定位这些具体瓶颈，才能判断更换数据库是否值得承担数据搬迁和查询改写的成本。

把选择落到数据、查询、一致性和扩展方式

数据形态：独立实体之间的引用与唯一性若是长期规则，优先评估 PostgreSQL 的表和约束。记录主要作为完整聚合变化、属性差异较大时，重点评估 MongoDB；关系稳定而附加属性多变时，可比较普通列与 jsonb 的组合。
查询模式：记录经常按关联条件重新组合，应检查关系模型及相应索引。请求通常按聚合标识取回整份记录，则检查文档边界是否与读取范围一致，并计入过滤、排序和索引维护的成本。
一致性：写清一次业务动作涉及哪些独立对象、哪些修改必须共同提交，以及失败后如何恢复。事务支持是一项能力，实际成本还取决于记录边界和并发争用。
扩展方式：计划为 MongoDB 分片时，要同时考察写入能否分散、常见查询能否定位目标分片。MongoDB 的分片键指南指出，低基数、取值集中或单调变化的键会影响分布；查询缺少分片键条件时，还可能发往所有分片。

现有系统值得迁移的前提，是目标模型能持续改善主要读写路径，且收益足以覆盖数据搬迁、查询改写与后续运维。若新项目尚未形成这些证据，就先按数据关系和操作边界选型，再用接近实际负载的测试检验性能假设。