为什么 Postgres RDS 对我们不管用

原文 ↗ Hacker News 讨论 ↗

对亚马逊托管 Postgres（RDS 和 Aurora）的批评主要集中在：对于在现代标准下并不算大的分析型和时序型工作负载，它们的性能不佳，而且基于 I/O 的成本出人意料地高。评论者认为，只要自建在高速本地存储上，或结合 TimescaleDB、Citus 等工具扩展，通用 Postgres 完全可以高效处理从数千万到数十亿行的数据；而像 ClickHouse、InfluxDB 这类专用列式或时序数据库往往更合适。更广泛的主题是重新审视云数据库的权衡：为托管服务和弹性付费，还是在裸金属、VPS 或其他托管服务商上运行更便宜、更快的方案。

RDS / AWS 成本与性能

  • 许多人认为核心问题在于 RDS 和 EBS 的配置，而不是 Postgres 本身。
  • RDS 被描述为明显比 EC2 或裸金属更昂贵，尤其是在预置 IOPS 方面；一些人提到与本地部署相比，成本差距可达一个数量级。
  • EBS 带宽积分以及较小实例规格上“最高可达”的性能受到批评，原因是其不透明且很容易踩坑。
  • 据称 Aurora 比普通 RDS 更快也更可预测，但由于 I/O 计费，成本会变得非常高；一些人表示，你主要是为了它的高可用/复制模型而采用它，而不是为了原始性能。

数据集规模与 Postgres 能力

  • 文中所说“很大”的 2000 万行时序表被广泛认为其实很小。
  • 多位评论者提到在 Postgres/Timescale/Aurora 中运行数十亿到数万亿行数据，这意味着文章中的问题很可能源于设计、索引或配置不佳，而不是 Postgres 的固有限制。

选择合适的数据库引擎

  • 对于使用通用 Postgres 做重度分析型全表扫描，出现了强烈反对；有人推荐列式或 OLAP 系统（ClickHouse、DuckDB、Redshift、Snowflake）。
  • 对于时序数据，建议使用专门系统（TimescaleDB、ClickHouse、InfluxDB、Prometheus）；权衡如下：
    • Timescale：完整 SQL 和关系型连接、列式压缩，适合分析。
    • ClickHouse：分析场景下压缩率和速度都非常高；有几个人提到把时序数据迁移到那里，同时把元数据保留在 Postgres 中。
  • 也有人认为，先把 Postgres 作为通用工具起步是合理的，等瓶颈明确后再把负载卸载到专门的数据库。

高可用与运维

  • 一派认为 Postgres 仍然没有“好”的高可用方案。
  • 另一派认为，只要理解其中的权衡，高可用其实“非常好”：流复制（单主）、Patroni/pg_auto_failover、Citus/Timescale 和 Aurora 都被提到。
  • 有人担心，自行搭建 Postgres 的运维负担很重，而托管服务可以把升级、备份和故障切换交出去。

云端 vs 自建基础设施

  • 多条评论描述了从 RDS/AWS 迁移到运行在 EC2、VPS、裸金属或 colo 上、并使用本地 NVMe 的自建 Postgres 后，节省显著且性能更好。
  • 反方观点是：对于优先考虑降低运维开销和内置高可用，而不是原始成本的团队，托管服务仍然很有吸引力。

存储后端争论（EBS、SSD、ZFS）

  • 有几个人认为，由于相较本地 SSD 延迟更高，关系型数据库在 EBS 上天然更慢；有人声称性能差异约为 10 倍。
  • 也有人指出，更高端的 EBS 层级在更高成本下可以接近 SSD 级别的延迟。
  • 关于 ZFS 的争论也在继续：有人警告其历史上的数据损坏 bug；也有人坚持它的长期表现优于替代方案，大多数问题都源于劣质硬件。

关于文章的元讨论

  • 一些人认为，这个故事更像是糟糕技术领导或工具选择不当的证据，而不是对 Postgres 的根本性否定。
  • 也有人把批评扩大到 AWS 的定价和复杂性。
  • 对于重复投稿以及通用的 Medium“英雄图”，有人表示怀疑和不满，但这只是附带意见。