Postgres se está comiendo el mundo de las bases de datos

Comportamiento y control del planificador de consultas

• Varios comentaristas elogian Postgres, pero se quejan de su planificador de consultas no determinista.
• Puntos dolorosos: el planificador eligiendo escaneos secuenciales o índices “equivocados”, oscilaciones drásticas de rendimiento por pequeños cambios en los predicados, problemas con el orden de unión y límites de colapso en la reordenación de joins.
• Soluciones de contorno mencionadas: EXPLAIN ANALYZE, desactivar tipos específicos de planes (enable_seqscan = off, etc.), ajustar random_page_cost, CLUSTER para mejorar la correlación entre índice y tabla, y reescribir joins.
• Algunos quieren sugerencias explícitas de planes; otros argumentan que el planificador suele acertar y que los problemas a menudo se deben a estadísticas, vacuuming o al diseño del esquema/consulta.
• Extensiones de terceros como pg_hint_plan ofrecen influencia manual sobre el plan.

Vistas materializadas / incrementales

• Gran interés en el mantenimiento incremental de vistas para mantener análisis complejos “actualizados” en tiempo real.
• Solución de contorno habitual actual: vistas materializadas más refresco programado (por ejemplo, pg_cron).
• Existen extensiones como pg_ivm, pero tienen muchas restricciones; esto podría explicar por qué no forma parte del núcleo.
• Debate sobre la viabilidad: algunos lo ven como “solo un índice sobre una consulta”, mientras que otros señalan sistemas de differential dataflow (Materialize, Noria, frameworks de streaming) como prueba de que es posible, aunque complejo.

Administración, actualizaciones y experiencia operativa

• Muchos informan que Postgres ahora es fácil de administrar; se considera que autovacuum funciona bien.
• Se dice que las actualizaciones in-place funcionan bien, pero algunos aún experimentan flujos de trabajo dolorosos de dump/restore, especialmente con extensiones como PostGIS.
• Entre las herramientas mencionadas están pgAdmin, dBeaver y clientes web; las experiencias con pgAdmin son mixtas.

Uso con .NET / EF Core

• Múltiples informes de uso en producción sin problemas con EF Core y el proveedor Npgsql.
• En general se describe como estable, eficiente y actualizado con rapidez.

Comparaciones, límites y alternativas

• Postgres es ampliamente elogiado como un valor predeterminado versátil; algunas empresas lo estandarizan en lugar de Oracle/MySQL.
• Los escépticos señalan deuda técnica, el modelo proceso-por-conexión, la amplificación de escrituras y su escaso encaje en sistemas transaccionales de altísimo rendimiento o casos de uso distribuidos orientados primero a alta disponibilidad.
• Se considera que sistemas especializados (TigerBeetle, Cassandra/Dynamo, Kafka, Elastic, ClickHouse, DuckDB, SQLite) siguen siendo necesarios en ciertos nichos.
• Debate sobre el texto completo en Postgres: la FTS integrada se considera más débil que Elasticsearch, pero extensiones (ParadeDB, PGroonga, pg_trgm, pgvector, búsqueda híbrida) mejoran significativamente las capacidades.

Ecosistema, compatibilidad y hype

• Las extensiones y la compatibilidad de protocolo se ven como fortalezas importantes; muchas “bases de datos nuevas” se perciben como respaldadas por Postgres o adyacentes a Postgres.
• Algunos ven el entusiasmo por Postgres como una moda; otros señalan su historia de décadas y repetidos “ciclos de hype” en los que la gente vuelve después de probar sistemas de moda.
• Nuevos proyectos buscan compatibilidad con Postgres sin reutilizar su base de código, para aprovechar las herramientas existentes y las preferencias de los desarrolladores.