Por que o Postgres RDS não funcionou para nós

Custos e desempenho do RDS / AWS

• Muitos veem o problema central como sendo a configuração do RDS e do EBS, não o Postgres em si.
• O RDS é descrito como significativamente mais caro do que EC2 ou bare metal, especialmente para IOPS provisionadas; alguns citam diferenças de custo de uma ordem de grandeza em relação ao on-premises.
• Os créditos de largura de banda do EBS e o desempenho “até” em tamanhos menores de instância são criticados por serem opacos e fáceis de surpreender.
• O Aurora é relatado como mais rápido e mais previsível do que o RDS puro, mas pode ficar muito caro devido à cobrança por I/O; alguns dizem que ele é adotado בעיקרamente pelo modelo de HA/replicação, não por desempenho bruto.

Tamanho do conjunto de dados e capacidade do Postgres

• A tabela de séries temporais de 20M de linhas citada como “grande” é amplamente descartada como pequena.
• Vários კომენტadores mencionam operar com bilhões a trilhões de linhas em Postgres/Timescale/Aurora, o que sugere que os problemas do artigo provavelmente decorrem de mau design, indexação ou configuração, e não de limites inerentes do Postgres.

Escolhendo o mecanismo de banco de dados certo

• Há forte resistência ao uso de Postgres genérico para varreduras analíticas pesadas em tabelas inteiras; sistemas colunares ou OLAP (ClickHouse, DuckDB, Redshift, Snowflake) são recomendados.
• Para séries temporais, são sugeridos sistemas especializados (TimescaleDB, ClickHouse, InfluxDB, Prometheus); os trade-offs:
  • Timescale: SQL completo e joins relacionais, compressão colunar, bom para analytics.
  • ClickHouse: compressão e velocidade muito altas para analytics; vários mencionam migrar dados de séries temporais para lá e manter metadados no Postgres.
• Alguns argumentam que começar com Postgres como uma ferramenta generalista faz sentido, e depois descarregar para bancos especializados quando os gargalos ficarem claros.

Alta disponibilidade e operações

• Um lado afirma que o Postgres ainda não tem uma boa história de HA.
• Outros argumentam que a HA é “excelente” se você entende os trade-offs: replicação em streaming (um único primário), Patroni/pg_auto_failover, Citus/Timescale e Aurora são citados.
• Surgem preocupações sobre o peso operacional de manter seu próprio Postgres versus terceirizar upgrades, backups e failover para serviços gerenciados.

Infraestrutura em nuvem vs. auto-hospedada

• Vários comentários descrevem economias significativas e melhor desempenho ao migrar de RDS/AWS para Postgres auto-hospedado em EC2, VPS, bare metal ou colo com NVMe local.
• Contra-argumento: serviços gerenciados continuam atraentes para equipes que priorizam menor sobrecarga operacional e HA embutida em vez de custo bruto.

Debates sobre backend de armazenamento (EBS, SSD, ZFS)

• Vários argumentam que bancos de dados relacionais são inerentemente mais lentos no EBS devido à maior latência em comparação com SSD local; alguns afirmam diferenças de desempenho de cerca de 10x.
• Outros observam que camadas mais altas do EBS podem se aproximar da latência de SSD, mas com custo maior.
• O ZFS é debatido: alguns alertam sobre bugs históricos de corrupção; outros insistem que seu histórico é forte em comparação com alternativas, com a maioria dos problemas decorrendo de hardware ruim.

Meta-discussão sobre o artigo

• Alguns veem a história como evidência de má liderança técnica ou de escolha errada de ferramentas, e não como uma condenação fundamental do Postgres.
• Outros ampliam a crítica para a precificação e a complexidade da AWS.
• Há certo ceticismo sobre submissões repetidas e irritação com imagens genéricas de “hero” do Medium, mas esses são comentários secundários.