Por qué Postgres RDS no nos funcionó

Artículo original ↗ Discusión en Hacker News ↗

Las críticas a Postgres gestionado de Amazon (RDS y Aurora) se centran en el bajo rendimiento y en costes de I/O inesperadamente altos para cargas de trabajo de analítica y series temporales que, por los estándares actuales, son modestas. Los comentaristas sostienen que Postgres de propósito general puede manejar decenas de millones hasta miles de millones de filas de forma eficiente cuando se autoalojan en almacenamiento local rápido o se amplía con herramientas como TimescaleDB o Citus, y que las bases de datos columnar o especializadas en series temporales (por ejemplo, ClickHouse, InfluxDB) suelen encajar mejor. El tema de fondo es una reevaluación de las compensaciones de las bases de datos en la nube: pagar una prima por servicios gestionados y elasticidad frente a ejecutar configuraciones más baratas y rápidas en bare metal, VPS o proveedores gestionados alternativos.

Coste y rendimiento de RDS / AWS

  • Muchos ven el problema principal en la configuración de RDS y EBS, no en Postgres en sí.
  • Se describe RDS como significativamente más caro que EC2 o bare metal, especialmente para IOPS aprovisionadas; algunos citan diferencias de coste de un orden de magnitud frente a on-prem.
  • Se critica que los créditos de ancho de banda de EBS y el rendimiento “hasta” de tamaños de instancia pequeños sean opacos y fáciles de pisar.
  • Se informa que Aurora es más rápido y predecible que RDS sin más, pero puede volverse muy caro debido al cobro por I/O; algunos dicen que se adopta sobre todo por su modelo de HA/replicación, no por rendimiento bruto.

Tamaño del conjunto de datos y capacidad de Postgres

  • La citada tabla de series temporales de “gran tamaño” con 20M de filas es ampliamente desestimada como pequeña.
  • Varios comentaristas mencionan ejecutar miles de millones hasta billones de filas en Postgres/Timescale/Aurora, lo que sugiere que los problemas del artículo probablemente se deban a un mal diseño, indexación o configuración, más que a límites inherentes de Postgres.

Elegir el motor de base de datos adecuado

  • Hay una fuerte reacción en contra de usar Postgres genérico para escaneos completos analíticos pesados; se recomiendan sistemas columnar u OLAP (ClickHouse, DuckDB, Redshift, Snowflake).
  • Para series temporales, se sugieren sistemas especializados (TimescaleDB, ClickHouse, InfluxDB, Prometheus); compensaciones:
    • Timescale: SQL completo y joins relacionales, compresión columnar, bueno para analítica.
    • ClickHouse: compresión y velocidad muy altas para analítica; varios mencionan migrar allí los datos de series temporales y mantener los metadatos en Postgres.
  • Algunos sostienen que empezar con Postgres como herramienta todoterreno tiene sentido, y luego descargar trabajo a bases de datos especializadas cuando los cuellos de botella quedan claros.

Alta disponibilidad y operaciones

  • Una parte afirma que Postgres sigue sin tener una historia “buena” de HA.
  • Otros argumentan que la HA es “excelente” si se entienden las compensaciones: se citan la replicación por streaming (un único primary), Patroni/pg_auto_failover, Citus/Timescale y Aurora.
  • Se plantean preocupaciones sobre la carga operativa de montar Postgres por cuenta propia frente a externalizar actualizaciones, copias de seguridad y failover a servicios gestionados.

Infraestructura en la nube vs autoalojada

  • Varios comentarios describen ahorros significativos y mejor rendimiento al pasar de RDS/AWS a Postgres autoalojado en EC2, VPS, bare metal o colo con NVMe local.
  • Contrapunto: los servicios gestionados siguen siendo atractivos para equipos que priorizan menos carga operativa y HA integrada sobre el coste bruto.

Debates sobre el backend de almacenamiento (EBS, SSD, ZFS)

  • Varios sostienen que las bases de datos relacionales son intrínsecamente más lentas en EBS debido a la mayor latencia frente al SSD local; algunos afirman diferencias de rendimiento de ~10x.
  • Otros señalan que los niveles EBS de gama alta pueden acercarse a latencias similares a las de SSD, a un coste mayor.
  • ZFS se debate: algunos advierten sobre fallos históricos de corrupción; otros insisten en que su historial es sólido frente a alternativas, y que la mayoría de los problemas se deben a hardware defectuoso.

Meta-discusión sobre el artículo

  • Algunos ven la historia como evidencia de un mal liderazgo técnico o de una mala elección de herramientas, más que como una condena fundamental de Postgres.
  • Otros amplían la crítica al precio y la complejidad de AWS.
  • Hay algo de escepticismo por envíos repetidos y molestia por las genéricas “hero images” de Medium, pero eso son notas al margen.