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 que se traducen en reportes más rápidos y RPO horario sin castigar el disco.
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_tableestandarizado: 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_basebackupincremental: por primera vez, un backup físico puede construirse en base al anterior, sin copiar la base entera cada noche. Requieresummarize_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 que 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_basebackupincremental 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 --linkdesde 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
- PostgreSQL 17 — Release Notes oficiales
- Incremental backup en Postgres 17 — Robert Haas
- Stack Overflow Developer Survey 2024 — Databases
Si tu DBA te dice que el upgrade puede esperar, pedile una cosa: que corra EXPLAIN (ANALYZE, BUFFERS) sobre tres queries reales de producción. La respuesta está ahí.