PostgreSQL vs DynamoDB：自建掌控 vs 全托管弹性

这是一场两种世界观的对比：DynamoDB 是 AWS 全托管的键值/文档数据库，承诺"不用管容量，永远水平扩展，按用量付费"；PostgreSQL 是功能完备的开源关系库，给你 SQL 的全部表达力和对成本的完全掌控。

数据建模：先想查询，再建表

DynamoDB 中一切皆 Item，除主键外无结构要求：

await dynamodb.put({
  TableName: 'Users',
  Item: {
    userId: '123', email: 'user@example.com', name: 'John Doe',
    preferences: { theme: 'dark', notifications: true }  // 每个用户可不同
  }
}).promise();

灵活，但除主键外不做任何类型和必填校验。更关键的是：DynamoDB 的表设计是查询驱动的——你必须先列出所有访问模式，围绕它们设计主键和二级索引，事后再加查询路径代价很高。

PostgreSQL 是结构 + 灵活兼得：

CREATE TABLE users (
    user_id VARCHAR(50) PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE,
    name VARCHAR(255) NOT NULL,
    preferences JSONB DEFAULT '{}'   -- 变化快的部分进 JSONB
);

列定义守住完整性，JSONB 容纳弹性。而且 SQL 的即席查询能力意味着：事先没想到的查询，加个索引就能跑。

查询模式的天壤之别

• DynamoDB：GetItem（主键精确查）和 Query（分区键 + 排序键条件）飞快且稳定；超出主键设计的查询只能 Scan 全表扫——贵且慢，生产环境基本禁用；
• PostgreSQL：任意字段、任意组合的 WHERE/JOIN/聚合，优化器自动选路径。表达力是 DynamoDB 的超集。

关系处理

• PostgreSQL：Join 是母语，外键保证引用完整；
• DynamoDB：没有 Join。多实体关联要么应用层多次查询拼装，要么把关联数据预聚合进同一个 Item 集合（单表设计范式）。单表设计强大但学习曲线陡峭，且把查询逻辑固化进了物理布局。

扩展方式：自动 vs 规划

# DynamoDB：自动扩展，数据增长自动再分区，性能与规模无关
# ——但每个请求都在计费
aws application-autoscaling register-scalable-target \
    --service-namespace dynamodb --resource-id table/Users ...

# PostgreSQL：纵向扩容调参数，横向靠读副本/连接池/分片扩展
max_connections = 200
shared_buffers = 4GB
effective_cache_size = 12GB

成本结构完全相反：DynamoDB 是变动的按量计费（流量洪峰时账单也洪峰），PostgreSQL 是相对的固定成本（机器钱 + 运维人力）。流量平稳且可预测时 PostgreSQL 通常便宜得多；流量尖峰剧烈且不愿运维时，DynamoDB 的弹性值回票价。

事务与一致性

• DynamoDB：默认最终一致读（强一致读要显式声明且更贵），支持事务 API 但有限额和额外开销；设计哲学是"为可用性优化"；
• PostgreSQL：标准 ACID，强一致是默认值，隔离级别可选。

涉及资金、库存的强一致场景，PostgreSQL 的默认行为就是你要的行为。

索引策略

• DynamoDB：GSI（全局二级索引）和 LSI（本地二级索引）要预先定义，GSI 有自己的吞吐配额和成本；
• PostgreSQL：B-Tree、GIN、GiST、BRIN、部分索引、表达式索引……按需创建，18 还新增 Skip Scan 让复合索引利用率更高。

运维考量

DynamoDB 把运维几乎清零：无服务器、无备份脚本、无版本升级，这是它最被低估的价值。PostgreSQL 即使上 RDS 也要管参数、扩容、备份策略、大版本升级——换来的是无厂商锁定（可迁移到任何云或自建）和精细的成本控制。

决策速查

观测云对照

两类库的观测路径不同：DynamoDB 重点盯云服务指标（限流、延迟、容量消耗）；PostgreSQL 重点盯数据库内部（慢查询、锁、复制延迟）。观测云 DataKit 同时覆盖云产品指标采集与 PostgreSQL 深度指标，可在同一平台对照两套系统的表现与告警，混合架构也不用切换工具。 1 2

常见问题（FAQ）

Q：DynamoDB 真的"无限扩展"吗？
扩展性是真实的，但有两个前提：分区键设计避免热点（高基数、均匀分布）；预算承受得住按需计费。设计差的表在高负载下照样被限流。

Q：能从 DynamoDB 迁到 PostgreSQL 吗？
可以但工作量不小：数据导出容易，难的是把围绕主键设计的访问模式重新翻译成关系模型和 SQL。选型时就要想清楚退路。

Q：DynamoDB 单表设计值得学吗？
确定用 DynamoDB 就值得——它是发挥该库性能的正统范式。但如果你的团队看到"把所有实体塞进一张表"就直觉抗拒，这个抗拒往往是对的：说明你的业务本质是关系型的。

参考资料

• 观测云集成功能
• 观测云监控器与告警