Postgres 17 en producción: tres cosas que cambian para una pyme

Streaming I/O, json_table y backups incrementales: las novedades de PostgreSQL 17 qué se traducen en reportes más rápidos y RPO horario sin castigar el disco.

ULTIMA MILLA · Técnico · 24 de abr de 2026 · 5 min de lectura


Martes a la mañana. Un DBA de una fintech mendocina mira la alerta. La query de reporting que corre a las 07:00 y tardaba 14 segundos ahora tarda 41. Nada cambió en el código. Se actualizó el kernel del server, eso sí. Spoiler: no fue el kernel. Fue que el read ahead del disco, un NVMe Samsung, empezó a competir con el buffer manager de Postgres 14 por prefetch de páginas. En Postgres 17 ese choque desaparece. Y no porque lo arreglaron a mano, sino porque el motor aprendió a leer diferente. ## Lo que cambió debajo del capó Las release notes oficiales de PostgreSQL 17, publicadas el 26 de septiembre de 2024, listan 2.500+ cambios. Tres importan para una pyme argentina que corre su ERP o su facturación sobre Postgres: - Streaming I/O API: el motor ahora pide al kernel varias páginas contiguas en un solo syscall en vez de una por una. En sequential scans sobre tablas > 2 GB, la diferencia medida por el equipo de PostgreSQL llega a 30% menos wall clock en discos NVMe locales (post de Melanie Plageman, commit fest). - json_table estandarizado: ya no hay que escribir CTEs de 40 líneas para explotar un JSON de logs en columnas. La sintaxis ANSI-SQL/JSON entró al motor tal cual la pide el estándar. - pg_basebackup incremental: por primera vez, un backup físico puede construirse en base al anterior, sin copiar la base entera cada noche. Requiere summarize_wal = on. El costo en CPU es marginal (~3% según el propio Robert Haas, autor del feature).

Por qué no es "otra upgrade más"

La industria venía acostumbrada a releases con un feature grande visible (particionamiento en 10, paralelismo en 11, MERGE en 15). Postgres 17 no tiene ese titular. Tiene algo menos marketinero: la infra por debajo se reescribió. Para una pyme que corre Odoo 18, Dolibarr o un Directus arriba de Postgres, eso significa dos cosas concretas qué se miden, no se prometen. La primera: reportes mensuales que antes corrían en 10 minutos pasan a correr en 7 u 8, sin tocar una línea de SQL. La encuesta de Stack Overflow 2024 reporta que Postgres es la base más usada del mundo entre desarrolladores profesionales (48,7%). El upgrade path desde 15 o 16 es trivial con pg_upgrade; el freno real son las extensiones. La segunda: backup incremental horario se vuelve viable sin castigar el disco. Para un ERP self-hosted con 180 GB de datos y 12 GB de WAL diario, la diferencia entre pg_basebackup full nocturno y un delta cada hora es el RPO que un estudio contable o una empresa constructora pueden comprometerle a un cliente.

Qué stack arma hoy una pyme argentina sobre Postgres 17

La configuración que vemos repetirse en 2026 en pymes de Cuyo y Buenos Aires: - DB: Postgres 17 sobre Debian 12 o Rocky 9, NVMe local, shared_buffers = 25% RAM, effective_io_concurrency = 200. - Réplica: streaming replication a una segunda VM en otro AZ o proveedor distinto (regla simple: nunca ambas en el mismo datacenter). - Backup: pg_basebackup incremental cada hora + WAL archive continuo a un bucket S3-compatible (MinIO self-hosted o Backblaze B2). - Observabilidad: pg_stat_statements + pgBadger + Grafana. Alertas de lag de réplica y de bloqueos pesados a Slack o Telegram. - Upgrade: pg_upgrade --link desde 15/16. Para un Odoo 18 sobre Postgres 15, la migración suele tomar entre 30 y 50 minutos de downtime para bases de hasta 50 GB, dependiendo del volumen de objetos grandes. ## Los tres "sí, pero…" Uno. json_table es potente, pero mueve lógica que antes estaba en la aplicación al motor. Conviene correr EXPLAIN (ANALYZE, BUFFERS) antes de promover la feature a producción, especialmente en queries que escanean JSON de más de 1 MB. Dos. Los backups incrementales dependen de summarize_wal. Si se apaga por error, el próximo incremental falla en silencio hasta la próxima full. Monitorear la señal, no asumir. Tres. Extensiones críticas —pgvector, timescaledb, pg_cron— no siempre están al día con el release. Revisar la matriz de compatibilidad antes de agendar el cambio, no después.

Para seguir leyendo