Postgres não é lento, seu armazenamento é
Muitos engenheiros atribuem a lentidão do PostgreSQL ao próprio banco de dados, mas comentaristas argumentam que escolhas da era da nuvem, como armazenamento anexado pela rede (por exemplo, EBS) e esquemas ou queries subótimos, costumam ser os verdadeiros gargalos. Eles contrapõem NVMe local e índices cuidadosamente ajustados ao armazenamento em blocos gerenciado e replicado, destacando trade-offs entre latência, simplicidade operacional, confiabilidade e custo. O debate também aborda temas mais amplos: como abstrações da nuvem obscurecem a realidade do hardware, quando bancos de dados especializados ou até mesmo SQLite em discos locais rápidos podem superar configurações pesadas, e a crescente frustração com conteúdo técnico gerado por IA.
Conteúdo “slop” percebido como gerado por IA
- Vários comentaristas acham que títulos e prosa de blogs estão cada vez mais parecendo gerados por LLMs, o que os deixa menos inclinados a ler, mesmo quando o tema é relevante.
- Outros reagem, observando que o padrão “X não é lento, Y é” precede os LLMs em muito tempo.
- Há frustração recorrente com acusações constantes de autoria por IA; alguns acham as queixas sobre o meta-assunto mais irritantes do que o possível conteúdo de IA.
- Ideias levantadas: rótulos automatizados de detector de IA em links do HN, ou rótulos voluntários de “assistido por IA”, para que os leitores filtrem se quiserem.
O que realmente torna o Postgres “lento”?
- Um grupo: o armazenamento muitas vezes é o gargalo, especialmente volumes em nuvem anexados pela rede versus NVMe local; são relatadas quedas reais de latência (por exemplo, 1,0ms → 0,1ms) após a migração para NVMe local.
- Outro grupo: o design do esquema e as queries são mais frequentemente o verdadeiro problema do que o armazenamento — indexação ruim, esquemas “portáveis” e falta de ajuste específico para o banco de dados.
- Alguns destacam técnicas específicas do Postgres: index-only scans / índices covering, layout de índices (“Tetris de colunas”), gestão de bloat de índices e estatísticas realistas em produção.
- Consenso: tanto o armazenamento quanto o design do esquema/das queries importam; nenhum dos dois, sozinho, consegue compensar uma fraqueza extrema no outro.
Armazenamento em nuvem vs discos locais
- Muitos criticam o armazenamento em blocos na nuvem (por exemplo, EBS) como lento e caro em comparação com NVMe local, argumentando que a nuvem esconde quão rápido o hardware moderno realmente é.
- Os defensores enfatizam benefícios operacionais: replicação fácil, failover, redimensionamento, snapshots e não precisar gerenciar RAID, sobressalentes e emergências às 3 da manhã.
- Há um debate detalhado sobre custo: alguns dizem que a nuvem é “insanamente cara” em comparação com bare metal alugado; outros observam o aumento dos preços do hardware on-premises e as economias de mão de obra/tempo da nuvem.
- Vários apontam que a replicação no nível da aplicação com NVMe local pode superar o armazenamento em rede, mas exige engenharia séria e disciplina operacional.
Alternativas, especialização e aceleração de hardware
- SQLite em NVMe local é elogiado por latência ultrabaixa em cenários de nó único (aplicações web, servidores de jogos), com preocupações principalmente sobre durabilidade e backups.
- DuckDB + NVMe é visto como excelente para analytics, mas limitado por restrições de concorrência.
- Alguns especulam sobre bancos de dados altamente especializados gerados por LLMs; a maioria das respostas enfatiza confiabilidade, ecossistema e a imensa complexidade de construir um DBMS.
- Há interesse em aceleração por hardware (FPGAs, SmartSSDs, GPUs) para joins e scans, embora comentaristas observem barreiras comerciais e operacionais.