Why Postgres RDS didn't work for us

Original Article ↗ Hacker News Discussion ↗

Critiques of Amazon’s managed Postgres (RDS and Aurora) center on poor performance and unexpectedly high I/O-based costs for analytics-style and time-series workloads that are modest in size by modern standards. Commenters argue that general-purpose Postgres can handle tens of millions to billions of rows efficiently when self-hosted on fast local storage or extended with tools like TimescaleDB or Citus, and that specialized columnar or time-series databases (e.g., ClickHouse, InfluxDB) are often a better fit. The broader theme is a reassessment of cloud database trade-offs: paying a premium for managed services and elasticity versus running cheaper, faster setups on bare metal, VPSs, or alternative managed providers.

RDS / AWS Cost and Performance

  • Many see the core issue as RDS and EBS configuration, not Postgres itself.
  • RDS is described as significantly more expensive than EC2 or bare metal, especially for provisioned IOPS; some cite order‑of‑magnitude cost gaps vs on‑prem.
  • EBS bandwidth credits and “up to” performance on smaller instance sizes are criticized as opaque and easy to trip over.
  • Aurora is reported as faster and more predictable than plain RDS but can become very costly due to I/O charging; some say you adopt it mainly for its HA/replication model, not raw performance.

Dataset Size and Postgres Capability

  • The cited “large” 20M‑row time‑series table is widely dismissed as tiny.
  • Multiple commenters mention running billions to trillions of rows in Postgres/Timescale/Aurora, implying the article’s problems likely stem from poor design, indexing, or configuration rather than inherent Postgres limits.

Choosing the Right Database Engine

  • Strong pushback against using generic Postgres for heavy analytical full‑table scans; columnar or OLAP systems (ClickHouse, DuckDB, Redshift, Snowflake) are recommended.
  • For time series, specialized systems (TimescaleDB, ClickHouse, InfluxDB, Prometheus) are suggested; tradeoffs:
    • Timescale: full SQL and relational joins, columnar compression, good for analytics.
    • ClickHouse: very high compression and speed for analytics; several mention migrating time‑series data there while keeping metadata in Postgres.
  • Some argue starting with Postgres as a generalist tool is sensible, then offloading to specialized DBs once bottlenecks are clear.

High Availability and Operations

  • One side claims Postgres still lacks a “good” HA story.
  • Others argue HA is “excellent” if you understand the tradeoffs: streaming replication (single primary), Patroni/pg_auto_failover, Citus/Timescale, and Aurora are cited.
  • Concerns are raised about the operational burden of rolling your own Postgres vs offloading upgrades/backups/failover to managed services.

Cloud vs Self‑Hosted Infrastructure

  • Multiple comments describe significant savings and better performance by moving from RDS/AWS to self‑hosted Postgres on EC2, VPS, bare metal, or colo with local NVMe.
  • Counterpoint: managed services remain attractive for teams that prioritize reduced ops overhead and built‑in HA over raw cost.

Storage Backend Debates (EBS, SSD, ZFS)

  • Several argue relational databases are inherently slower on EBS due to higher latency vs local SSD; some claim ~10x performance differences.
  • Others note higher‑end EBS tiers can approach SSD‑like latency, at higher cost.
  • ZFS is debated: some warn about historic corruption bugs; others insist its track record is strong compared to alternatives, with most issues due to bad hardware.

Meta‑Discussion About the Article

  • Some see the story as evidence of bad technical leadership or mis‑tooling rather than a fundamental indictment of Postgres.
  • Others broaden the criticism to AWS pricing and complexity.
  • There is some skepticism about repeated submissions and annoyance at generic Medium “hero images,” but these are side notes.