Qué trae de nuevo Postgres 19: análisis a fondo de la versión beta

• La versión beta incorpora REPACK CONCURRENTLY en el núcleo para bases de datos de producción a gran escala, además de mejoras amplias en consultas de grafos de propiedades SQL, replicación lógica, VACUUM, rendimiento y más
• El soporte para fusionar y dividir particiones, junto con la sincronización de valores de secuencia, facilita mucho más los cambios de diseño y el movimiento de datos en sistemas en operación
• Se introducen workers paralelos y un sistema de puntuación por prioridad en autovacuum, mejorando el rendimiento y la visibilidad de las tareas de mantenimiento
• Con SQL/PGQ, ahora es posible consultar datos existentes en forma de grafo sin abandonar el modelo relacional
• La clave no es una sola función destacada, sino la amplitud (breadth): avances simultáneos en aplicaciones, operaciones, rendimiento y escalabilidad

---

REPACK integrado por defecto

• En entornos de operación de largo plazo, se repite con frecuencia la necesidad de recuperar bloat de tablas, reescribir tablas o reorganizar datos sin sufrir los bloqueos que traen VACUUM FULL o CLUSTER
  • Ya existía un ecosistema de extensiones para resolver este problema, y pg_repack fue uno de los ejemplos más representativos
• Postgres 19 incorpora el comando REPACK al núcleo, incluyendo soporte para REPACK CONCURRENTLY
  • Se espera que sea una función más relevante para usuarios de producción de lo que suele anticipar el lector promedio de las notas de lanzamiento

Más utilidad práctica para el particionamiento

• Postgres 19 añade soporte para fusionar y dividir particiones
• Las estrategias de particionamiento suelen elegirse con información incompleta, y cuando cambian la carga, la retención o la velocidad de crecimiento de los datos, algunas particiones pueden volverse demasiado grandes o demasiado pequeñas
• Al poder dividir y fusionar, se gana margen para hacer evolucionar el diseño con el tiempo sin tener que reconstruir todo desde cero
  • Ejemplo de fusionar las particiones Q1 y Q2 en una sola: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
  • También se muestra un ejemplo de SPLIT PARTITION para dividir la partición de Q3 por mes

La madurez de la replicación lógica

• La replicación lógica es útil para migraciones, upgrades, sistemas de reporting, movimiento de datos, replicación selectiva y flujos operativos o de alta disponibilidad
• La mejora más importante es la sincronización de valores de secuencia, que hace que el suscriptor quede mucho más alineado con el publicador
  • Si se replica sin el estado de las secuencias, los datos se mueven, pero después del cutover aparecen problemas porque el siguiente ID generado no coincide
  • Se añade soporte para ALL SEQUENCES en la publicación, reporte de errores de sincronización de secuencias y mejoras en el comportamiento de actualización de suscripciones relacionadas con secuencias
• Ahora se puede usar la cláusula EXCEPT para publicar todas las tablas salvo algunas específicas
• Si hace falta wal_level = replica, la replicación lógica se activa automáticamente, y además se incorpora effective_wal_level para reportar el comportamiento real, reduciendo errores de configuración y mejorando la visibilidad

Autovacuum más inteligente y más visible

• Autovacuum puede usar workers de vacuum paralelos, con control tanto global como por tabla
  • Ejemplo de configuración global: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
• Se introduce un nuevo sistema de puntuación para controlar el orden en que se hace vacuum sobre las tablas, mejorando la priorización de cuáles requieren atención más urgente
  • Ejemplo de ajuste por tabla: urgencia 3.0 para vacuum basado en inserts y urgencia 0.5 para vacuum normal por updates/deletes
• La nueva vista pg_stat_autovacuum_scores da visibilidad al proceso de toma de decisiones
  • También se refuerza la observabilidad del mantenimiento con más detalle en las vistas de progreso de vacuum y analyze, uso de memoria y paralelismo en VACUUM VERBOSE y en los logs de autovacuum, además de un nuevo log_autoanalyze_min_duration

Llegan las consultas de grafos de propiedades SQL

• Se agrega SQL/PGQ (SQL property graph queries)
  • Se mencionan cargas donde el modelo de vértices y aristas resulta útil, como detección de fraude, recomendaciones, análisis de redes, grafos de permisos, cadenas de suministro y organigramas
  • Se muestra un ejemplo de definición de grafo de propiedades con CREATE PROPERTY GRAPH store_graph, indicando VERTEX TABLES y EDGE TABLES
• La idea no es abandonar el modelo relacional, sino sumar otra forma de consultar datos que ya existen
  • Va en la misma línea de JSONB, búsqueda de texto completo y extensiones, que no obligaron a cambiar la arquitectura existente
• Desde la perspectiva del desarrollador, esto permite usar consultas de tipo grafo sin sumar otro datastore, rutas de sincronización, superficie operativa ni más cosas que depurar a las 2 a. m.

COPY ahora es más útil

• COPY FROM ahora puede omitir varias líneas de encabezado
  • Esto sirve para procesar CSV exportados por proveedores, herramientas internas o sistemas que agregan líneas extra de metadatos al inicio
• COPY FROM suma ON_ERROR SET_NULL, que permite convertir entradas inválidas en null, ofreciendo una opción intermedia entre “fallar toda la carga” y “limpiar todo previamente”
  • Se muestra un ejemplo de carga de un archivo donde la columna price mezcla valores como 'N/A' y 'MISSING'
• COPY TO puede emitir JSON, incluyendo un solo arreglo JSON, y también exportar directamente tablas particionadas (antes hacía falta COPY (SELECT ...))
  • Ejemplo para exportar una tabla como un arreglo JSON válido: WITH (FORMAT JSON, ARRAY true)

Mejoras de comodidad en SQL

• Con GROUP BY ALL, las expresiones de la lista que no son agregadas ni de ventana se agrupan automáticamente, haciendo más limpias las consultas SQL exploratorias y de reporting
• Las funciones de ventana ahora soportan IGNORE NULLS y RESPECT NULLS en lead, lag, first_value, last_value y nth_value
• Se añade INSERT ... ON CONFLICT DO SELECT ... RETURNING, lo que permite devolver más directamente la fila en conflicto dentro de un upsert
• También se agregan UPDATE y DELETE FOR PORTION OF, ampliando el soporte para operaciones temporales, junto con una versión extendida de la función temporal RANDOM()

Mejoras generales de rendimiento

• Hay múltiples mejoras en el planner y el ejecutor: anti-join, semi-join, constant folding, incremental sort en rutas append, agregación antes del join, cálculo de selectividad en joins, estadísticas de funciones y más
• Postgres sigue avanzando en reconocer mejor formas comunes de consulta y reducir trabajo innecesario
  • Parte de la agregación ahora puede ejecutarse antes del join para reducir la cantidad de filas procesadas
  • Más casos de NOT IN y LEFT JOIN pueden transformarse en anti-joins eficientes
  • También mejora la visibilidad de Memoize en EXPLAIN, el rendimiento de ordenamiento con radix sort, la velocidad de verificación de restricciones de clave foránea y el uso de instrucciones SIMD en entradas de texto y CSV de COPY FROM
• En muchos casos, basta con hacer el upgrade para obtener mejoras sin cambiar el código de la aplicación

Por qué importa Postgres 19

• Lo más llamativo no es una sola función, sino su amplitud (breadth)
  • Para desarrolladores de aplicaciones: consultas de grafos, sintaxis SQL mejorada, mejoras en funciones de ventana y mejor comportamiento de upsert
  • Para operadores: REPACK CONCURRENTLY, autovacuum mejorado, monitoreo más completo, cambio de checksums en línea y mayor visibilidad de la replicación
  • Para usuarios enfocados en rendimiento: mejoras del planner, optimizaciones SIMD, visibilidad de I/O asíncrono, validación más rápida de claves foráneas y mejores ordenamientos
  • Para quienes construyen sobre Postgres: nuevos hooks, módulo de asesoría del planner, mejoras en extensiones, consulta de estadísticas de FDW y continuidad en la inversión del ecosistema de extensiones
• No evoluciona solo para una carga o perfil específico, sino al mismo tiempo como base de datos y plataforma para aplicaciones, operaciones, análisis y extensibilidad
• Aún no es GA, así que este es el momento de probar: ejecutar aplicaciones, validar migraciones, revisar extensiones, comprobar planes de consulta clave y evaluar flujos de replicación lógica y mantenimiento

[GN⁺]

Opiniones de Hacker News

• He usado Postgres, Oracle, MS SQL Server y MySQL en proyectos reales, y aunque no he usado SQLite a fondo, sé que es una excelente opción.
  Hoy en día, por mi cuenta, siempre evito Oracle y MySQL/MariaDB.
  Postgres es excelente, pero me gustaría que tuviera conexiones livianas y vistas materializadas con actualización sincrónica. Aunque los connection poolers mejoran la situación, el uso de memoria por conexión concurrente sigue siendo anormalmente alto, y una función como las vistas indexadas de SQL Server permite implementaciones elegantes, triviales y siempre correctas en escenarios de datos complejos.
  SQL Server puede ser caro, pero en muchos casos vale lo que cuesta, y elegir con cuidado el almacén de datos puede reducir muchos dolores de cabeza futuros.

  • Para problemas de almacenamiento relacional uso principalmente SQLite y MSSQL.
    Si vas a usar un proveedor gratuito, es difícil superar a SQLite, y hoy cubre la mayoría de los casos de uso. Pero empieza a quedarse corto en backups, replicación y herramientas. Si tengo que hacerme responsable de la disponibilidad del sistema y de la recuperación ante desastres, no tengo problema en gastar dinero para reducir el riesgo.
    Si voy a pagar aunque sea un poco, voy hasta el final. La experiencia de desarrollo alrededor de MSSQL no tiene comparación, y creo que SSMS y los proyectos SQL de Visual Studio son mucho mejores que las opciones tipo Entity Framework de hoy. Si sumas herramientas de terceros como RedGate, pueden reemplazar paquetes de consultoría de millones de dólares.
    No propondría levantar un servidor nuevo de Oracle o DB2, pero si ya existe, probablemente me opondría hasta el final a refactorizar para eliminarlo. Estas bases de datos suelen venir con enormes historias de terror, y si no hay otra opción que reproducir esos efectos secundarios extraños en un motor nuevo, el negocio mismo puede romperse.
  • Oracle es una combinación de dolor, sufrimiento, costos altos, demandas y miseria humana. Creo que ya habría quebrado si no fuera por gerentes medios no técnicos a los que les gustan beneficios como buenas fiestas cuando compran software caro.
  • Incluso Microsoft parece haber abandonado prácticamente SQL Server y dedicar más tiempo a mejorar sus distintos productos de Postgres en Azure. Después de 2022, la última versión importante solo agregó algunas funciones de IA.
    Como DBA, cuando haces mucho trabajo pesado de DBA, Postgres está en otra categoría frente a SQL Server. Postgres es nativo de Linux y open source, así que su flexibilidad, observabilidad interna y operabilidad no tienen comparación con SQL Server.
    En el panorama tecnológico actual, considero que SQL Server está básicamente muerto. Las empresas que lo usan son organizaciones legacy centradas en Windows, y esas también son cada vez menos.
  • Realmente me gustaría que existieran las vistas materializadas con actualización sincrónica. En terminología de Oracle, parece referirse a algo como “actualizar al hacer commit”.
    También estaría bueno tener una opción de actualización diferida. Sería una forma de procesar varias actualizaciones de una vez considerando solo los registros que cambiaron desde el último refresh; no sé bien cómo lo hace Oracle técnicamente. Esta función sería una adición fantástica frente a casi cualquier base de datos OLTP open source.
    También me interesa mucho el proyecto OrioleDB: https://github.com/orioledb/orioledb/releases
    Hace unos años sufrí bastante con vacuum por muchas inserciones y eliminaciones aleatorias continuas en algo parecido a tablas temporales. Lo resolví acumulando más cambios en RAM y luego haciendo flush a la tabla para aumentar la cantidad de filas modificadas por página, pero me costó mucho encontrar un buen equilibrio.
  • Aunque PostgreSQL es un producto mejor, no tiene la escalabilidad horizontal de MySQL/MariaDB. Por eso, si necesitas un clúster fácil de configurar y casos como una gran tienda minorista en línea, MySQL sigue siendo útil.

• Como alguien que ha usado Postgres durante más de 15 años en el ámbito científico, me empieza a preocupar que PostgreSQL no tenga almacenamiento orientado a columnas.
  A medida que los datasets crecen, las limitaciones del almacenamiento de PG se sienten cada vez más. Varias extensiones como cetus pueden ofrecer esa funcionalidad, pero entonces dependes de que esa extensión siga teniendo soporte en el futuro y además aumenta la complejidad.

  • Un poco de autopromoción descarada, pero llevo varios meses trabajando en este problema en forma de extensión: https://github.com/xataio/deltax
    Al principio pensé que, si usábamos tablas de Postgres como almacenamiento y el ejecutor de Postgres, el overhead intrínseco sería demasiado alto, así que igualar el rendimiento de Timescale ya sería bastante interesante. No pensaba que pudiera acercarse a una base de datos analítica dedicada.
    Pero a medida que avanzó el proyecto, el rendimiento siguió mejorando, y ahora apoyo claramente la idea de hacer trabajos analíticos con Postgres + una extensión.
  • Si esperas eso, puede que hayas elegido mal la base de datos. Las bases de datos orientadas a columnas son una categoría aparte.
    Es parecido a preocuparse porque Apple no venda lavadoras.
  • Desde el punto de vista de ciencias de la computación, no tengo claro cómo una base de datos transaccional implementaría algo columnar. Cuando crece la escala, una combinación como Postgres + CDC + ClickHouse, con una base de datos analítica real, parece la opción más fuerte.
  • Si tus datasets crecen cada vez más, parece mejor dejar los datos nuevos en PostgreSQL y archivar periódicamente los datos antiguos en una base de datos tipo data warehouse, para mantener Postgres pequeño.
    Hoy en día muchas empresas usan en su aplicación principal una base de datos relacional junto con una base de datos clave-valor o un almacén de documentos.
  • Como usuario desde hace 25 años, el estado actual me parece bien. Más no necesariamente es mejor, y Redis es un buen ejemplo de eso.

• No sé por qué no se habló de que PostgreSQL 19 introduce soporte nativo para datos temporales de application-time basado en el estándar SQL:2011: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

  • Me sorprende que el artículo original no lo haya mencionado. Antes se implementaba agregando manualmente triggers tcn y tablas sombra _archive: https://www.postgresql.org/docs/current/tcn.html
    Si esto se vuelve nativo, creo que será realmente excelente, como la mayoría de las implementaciones de PostgreSQL
  • También es una lástima que Query Hints apenas se mencionen. Hubo una discusión interesante bajo un artículo anterior con un título similar
    https://news.ycombinator.com/item?id=48413655
  • Es una función genial, pero sinceramente creo que será un poco difícil usarla bien. Y hay que tener cuidado de que la PII no quede mucho tiempo perdida en algún vacío temporal

• No sé si este artículo usa un estilo sobrerrepresentado en los datos de entrenamiento de los LLM, o si se usó mucho AI para pulirlo. Me inclino por lo segundo

  • Decir “pulirlo” es demasiado generoso. Me molesta más que la información del autor induzca a error. No se encuentra a craig-kerstiens en Hugging Face, y no hay una sola frase en este texto que parezca haber sido tecleada directamente
    Creo que cuando Claude escribe frases como “como alguien que ha trabajado mucho tiempo en X”, eso es una especie de fallo de alineación. Un LLM no debería escribir como si tuviera experiencia personal. Puede que en los datos de entrenamiento haya personas hablando así, pero aunque sea una secuencia de tokens estadísticamente plausible, creo que un LLM no debería afirmar experiencias de vida que no tiene
  • No hace falta ser tan generoso. Snowflake despidió a sus redactores técnicos diciendo que los reemplazaría con AI: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
  • Este tipo de comentarios de bajo esfuerzo que se quejan del estilo y el formato van contra las guías de discusión de Hacker News, y hace falta tomar medidas para limpiar los comentarios. Ya se volvió ridículo
  • Pangram determina que todo este texto fue generado por AI, pero no sé qué tan confiable sea Pangram. Me gustaría escuchar qué piensan los demás
  • Entiendo que está de moda especular sobre si se usó AI. Pero si hay algo que criticar, creo que es más útil criticar el resultado final

• Me gustan las mejoras en COPY y la replicación lógica. Actualmente respaldo una base de datos PG en una instancia sidecar de Databasus, y eso pesa más que todo el backend + la DB + Caddy
  Lo siguiente es una queja sobre el estilo de LLM
  Si Orwell viviera hoy, quizá habría declarado su analfabetismo en inglés y aprendido klingon antes que leer frases como “Eso por sí solo nos dice algo: los usuarios tenían una necesidad real y el ecosistema llenó el vacío”, “Parece simple, pero resuelve problemas reales de operación”, o “No va a cambiar el mundo, pero mejora los flujos de trabajo diarios con datos”

• Las funciones de base de datos de grafos se ven interesantes, pero la sintaxis de GRAPH_TABLE es espantosa
  SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
  Esto recuerda a neo4j, pero no creo que sea algo que una herramienta seria de 2026 deba copiar tal cual
  Al final, lo que me da curiosidad es la velocidad. La seguridad a nivel de fila es una función muy útil, pero intentar construir algo serio con la implementación de Postgres es imprudente. El planner se descompone y termina haciendo matching por cada fila, destrozando el rendimiento

  • Eso no es una sintaxis arbitraria inventada por Postgres
    Es SQL/PGQ, derivado del lenguaje Cypher de Neo4J y ahora parte del estándar SQL
  • ¿Dices que en la seguridad a nivel de fila el planner revisa fila por fila? Pues eso es justamente Row-level security. ¿De qué otra forma verificarías si una fila pasa la política?

• Me gustaría que PostgreSQL incorporara no solo compresión de filas, sino también compresión de bloques. La compresión de filas por sí sola tiene un efecto demasiado limitado
  Se puede poner los datos en un pool ZFS y activar la compresión de bloques, pero si hubiera soporte nativo se reduciría la carga de configuración y quizá el rendimiento sería mejor

• GROUP BY ALL tiene muchísimo sentido cuando lo piensas, y me parece curioso no haberlo considerado nunca antes

• Desde una perspectiva más cercana a DevOps, me gustaría que PostgreSQL por fin admitiera actualizaciones in-place entre versiones mayores consecutivas
  La mayoría de las distribuciones pueden lidiar con la molesta característica de ejecutar juntas la versión vieja y la nueva para pg_upgrade, pero con Docker actualizar a una nueva versión mayor es realmente doloroso

• Me alegra que se introduzca GROUP BY ALL. Que yo sepa, es un concepto que introdujo DuckDB
  La documentación de DuckDB también dice que varias funciones se introdujeron primero en DuckDB, y que funciones como GROUP BY ALL fueron adoptadas después por otros sistemas
  https://duckdb.org/docs/lts/sql/dialect/friendly_sql