DynamoDB vs PostgreSQL

DynamoDB 和 PostgreSQL 解决的是不同的问题。DynamoDB 是一款为扩展和可预测延迟而优化的无服务器 NoSQL 数据库；PostgreSQL 是一款为灵活查询和数据完整性而优化的成熟关系型数据库。本页对二者做客观对比，让你按工作负载而非按噱头来选择。

DynamoDB 和 PostgreSQL 有什么区别？

DynamoDB 是一款完全托管的无服务器键值和文档型 NoSQL 数据库，可在任何规模下提供个位数毫秒的性能，但没有 JOIN 运算符，因此你要围绕已知访问模式来建模数据。PostgreSQL 是一款开源的对象关系型 SQL 数据库，支持完整连接、丰富的类型系统和 ACID 事务，为临时的关系型查询而设计。请按访问模式、规模和查询灵活性来选择。

DynamoDB 与 PostgreSQL 速览

特性	DynamoDB	PostgreSQL
数据模型	NoSQL——同时支持键值和文档模型；每个项目模式灵活	对象关系型——带已定义且强制模式的表、行和列
查询语言	专用 API（`Query`/`Scan`/`GetItem`）以及用于 SELECT/INSERT/UPDATE/DELETE 的 SQL 兼容语言 PartiQL	完整 SQL；PostgreSQL 18 至少符合 SQL:2023 Core 177 项必选特性中的 170 项
连接与关系	无 JOIN 运算符；AWS 建议对数据模型做反范式化	完整的跨表关系型连接、外键和约束
索引	全局和本地二级索引让你按备用键查询	B 树、哈希、GiST、SP-GiST、GIN、BRIN，以及部分、表达式和覆盖索引
一致性	默认最终一致性；可选强一致性读；原生 ACID 事务	自 2001 年起兼容 ACID；通过 MVCC 默认提供强一致性
扩展	横向——自动为数据分区；无服务器按需模式可上下伸缩（可到零）	纵向扩展加只读副本以扩展读；写入横向扩展需要分区或外部工具
事务	服务端 ACID 事务，可跨一个或多个项目和表，受每请求限制约束	完整的多语句事务、保存点（嵌套事务）和 MVCC 并发
托管 / 部署	无服务器，仅限 AWS；按需或预置容量计费	开源，可在任意环境自托管；托管选项包括 Amazon RDS for PostgreSQL 和 Aurora PostgreSQL-Compatible Edition
最适合的工作负载	访问模式已知的高规模运营型应用（购物车、会话、排行榜、事件数据）	需要连接、临时查询和强数据完整性的关系型及分析型工作负载

何时 DynamoDB 是更好的选择

当你的访问模式已知，且你优先看重规模下可预测的延迟而非临时查询时，选 DynamoDB：

无论你有几百还是数亿用户，你都需要稳定的个位数毫秒读写。
你想要一款无服务器数据库，没有需要打补丁的服务器或需要规划的容量，并且按需计费在空闲时可缩至零。
你的工作负载面向键或项目（用户资料、会话、购物车、排行榜、事件流），契合 DynamoDB 的分区/排序键模型。
你想要多区域、多活复制以及高可用 SLA，而无需自建复制。

代价是：没有连接，而且你必须围绕将要运行的查询来设计键。事后重做访问模式比在 SQL 中更困难。

何时 PostgreSQL 是更好的选择

当查询灵活性和关系型完整性比横向扩展更重要时，选 PostgreSQL：

你需要跨规范化表做连接、聚合和临时查询，而且你的访问模式会持续演变。
你想要完整 SQL、丰富的类型系统（JSON/JSONB、数组、通过 PostGIS 的地理空间）以及用于数据完整性的强制约束。
你的数据集和流量适合一个纵向扩展的主库加只读副本，或者你愿意为写入横向扩展添加分区/分片工具。
你想自托管、避免单一供应商锁定，或在你选择的云上运行托管 Postgres。

代价是：相比无服务器 NoSQL 数据库，你要承担更多扩展和运维方面的工作，尤其是在极高写入吞吐量的情况下。

使用 DynamoDB 工作

一旦你选定了 DynamoDB，DynoTable 是一款专门为它打造的桌面客户端。它为你提供浏览和编辑项目的原生 GUI、一个可以在 DynamoDB 的访问模式规则内表达关系型形态查询的 SQL Workbench——连接、GROUP BY、聚合——方法是将它们编译成 DynamoDB 自己的 Query/Scan 操作，还有一个运行在你自己 AWS Bedrock 凭证之上的 AI 助手，让你的模式和数据留在你的账户里。如果你从 Postgres 转过来、怀念写 SQL，SQL for DynamoDB 指南和 PartiQL vs SQL 指南解释了哪些能映射过来、哪些不能。

对于快速的一次性查询，免费的 DynamoDB Expression Builder 可以生成正确的键条件、过滤表达式和更新表达式，并正确处理保留字和属性名——无需安装。

常见问题

DynamoDB 能替代 PostgreSQL 吗？

一般不能——它们面向不同的工作负载。对于访问模式定义明确、以无服务器扩展和可预测延迟为优先的高规模运营型应用，DynamoDB 可以替代 PostgreSQL。但在你依赖连接、临时关系型查询或不断演变的查询面时，它并不合适，而这些正是 PostgreSQL 的强项。许多团队两者并用：PostgreSQL 承担关系型和分析型工作，DynamoDB 承担高吞吐量的键访问路径。

DynamoDB 支持 SQL 或连接吗？

DynamoDB 支持 PartiQL，一种针对你的表进行 SELECT、INSERT、UPDATE 和 DELETE 的 SQL 兼容查询语言，但它不支持 JOIN 运算符——AWS 建议改为对数据做反范式化。PostgreSQL 支持包括跨表连接在内的完整 SQL。关于如何在没有原生连接的情况下建模关系，参见 DynamoDB JOIN 指南。

DynamoDB 比 PostgreSQL 便宜吗？

这取决于工作负载，所以要把成本当作需要建模测算的东西，而非想当然。DynamoDB 按读/写请求和已存储数据计费（按需或预置容量），并在空闲时缩至零，对于尖峰或低基线流量可能更便宜。像 Amazon RDS 或 Aurora 这样的托管 PostgreSQL 通常按持续运行的预置计算和存储计费，对于稳定、查询密集的工作负载可能更具成本效益。在决定之前，请对照你真实的访问模式对两者进行估算。