Postgres no es lento, tu almacenamiento sí lo es
Muchos ingenieros atribuyen la lentitud de PostgreSQL a la base de datos en sí, pero los comentaristas sostienen que las decisiones propias de la era cloud, como el almacenamiento conectado por red (p. ej., EBS) y esquemas o consultas subóptimos, suelen ser los verdaderos cuellos de botella. Comparan NVMe local e índices cuidadosamente ajustados con almacenamiento en bloque gestionado y replicado, destacando las ventajas y desventajas entre latencia, simplicidad operativa, fiabilidad y coste. El hilo también aborda temas más amplios: cómo las abstracciones de la nube ocultan la realidad del hardware, cuándo bases de datos especializadas o incluso SQLite en discos locales rápidos pueden superar a configuraciones más pesadas, y la creciente frustración con el contenido técnico generado por IA.
Contenido percibido como “slop” generado por IA
- Varios comentaristas sienten que los títulos de blogs y la prosa se parecen cada vez más a texto generado por LLM, lo que hace que tengan menos ganas de leerlos, incluso cuando el tema es relevante.
- Otros discrepan, señalando que el patrón de “X no es lento, Y sí lo es” existe desde mucho antes de los LLM.
- Hay una frustración recurrente por las acusaciones constantes de autoría por IA; a algunos les resultan más molestas las quejas sobre el tema que el posible contenido generado por IA.
- Ideas propuestas: etiquetas automáticas de detector de IA en enlaces de HN, o etiquetas voluntarias de “asistido por IA”, para que los lectores puedan filtrarlas si quieren.
¿Qué hace realmente que Postgres sea “lento”?
- Un bando: el almacenamiento suele ser el cuello de botella, especialmente los volúmenes en red de la nube frente a NVMe local; se reportan mejoras reales de latencia (p. ej., de 1,0 ms a 0,1 ms) tras pasar a NVMe local.
- Otro bando: el diseño del esquema y las consultas son con más frecuencia el verdadero problema que el almacenamiento: índices mal diseñados, esquemas “portables” y falta de ajuste específico para la base de datos.
- Algunos destacan técnicas concretas de Postgres: index-only scans / índices cubrientes, disposición de índices (“Tetris de columnas”), gestión del bloat de índices y estadísticas realistas en producción.
- Consenso: tanto el almacenamiento como el diseño del esquema y las consultas importan; ninguno por sí solo puede compensar una debilidad extrema en el otro.
Almacenamiento en la nube vs discos locales
- Muchos critican el almacenamiento en bloque de la nube (p. ej., EBS) por ser lento y caro en comparación con NVMe local, argumentando que la nube oculta lo rápido que es realmente el hardware moderno.
- Quienes lo defienden enfatizan las ventajas operativas: replicación sencilla, failover, redimensionamiento, snapshots y no tener que gestionar RAID, repuestos ni emergencias a las 3 de la mañana.
- Hay un debate detallado sobre costes: algunos dicen que la nube es “increíblemente cara” frente a bare metal alquilado; otros señalan el aumento de los precios del hardware on-prem y el ahorro de tiempo y trabajo de la nube.
- Varios apuntan que la replicación a nivel de aplicación sobre NVMe local puede superar al almacenamiento en red, pero requiere una ingeniería seria y disciplina operativa.
Alternativas, especialización y aceleración por hardware
- SQLite en NVMe local es elogiado por su latencia ultrabaja en escenarios de un solo nodo (aplicaciones web, servidores de juegos), con preocupaciones principalmente sobre durabilidad y copias de seguridad.
- DuckDB + NVMe se considera excelente para analítica, pero limitado por las restricciones de concurrencia.
- Algunos especulan sobre bases de datos altamente especializadas generadas por LLM; la mayoría de las respuestas subraya la fiabilidad, el ecosistema y la enorme complejidad de construir un DBMS.
- Hay interés en la aceleración por hardware (FPGAs, SmartSSDs, GPUs) para joins y scans, aunque los comentaristas señalan barreras comerciales y operativas.