PostgreSQL 18 llega con el cambio más profundo en el subsistema de I/O en quince años: lecturas y escrituras asíncronas nativas. Junto a eso, columnas generadas virtuales que eliminan duplicación de almacenamiento, autenticación OAuth 2.0 integrada al motor y mejoras SQL que resuelven patrones que antes requerían workarounds. Esta nota analiza qué cambia, qué workloads se benefician más y cuándo conviene planificar la migración en equipos de producción.
El cambio central: I/O asíncrono nativo
Durante más de una década, PostgreSQL leyó y escribió datos usando I/O sincrónico: el proceso backend esperaba que cada operación de disco completara antes de continuar. Con discos giratorios de 5-10 ms de latencia, esa espera era aceptable. Con SSDs NVMe que completan lecturas en 50-100 microsegundos y pueden procesar miles de operaciones en paralelo, la espera sincrónica dejaba rendimiento sobre la mesa.
PostgreSQL 18 introduce I/O asíncrono (AIO) en el subsistema de almacenamiento. El motor ahora emite múltiples solicitudes de I/O simultáneamente sin bloquear el proceso mientras espera las respuestas. Los benchmarks de carga mixta muestran mejoras de 30 a 80% en throughput según el patrón de acceso y el hardware de almacenamiento.
¿Qué workloads se benefician más?
El beneficio no es uniforme. Los que más ganan son:
- Sequential scans en tablas grandes: antes el backend leía bloque por bloque esperando cada lectura. Con AIO el prefetch es real y las páginas llegan antes de que el procesador las necesite.
- Checkpointing y autovacuum agresivo: el writer de background paraleliza las escrituras sucias, reduciendo la contención con los procesos de usuario.
- Múltiples conexiones concurrentes: varios backends haciendo I/O aprovechan mejor el ancho de banda del almacenamiento sin bloquearse entre sí.
Los workloads CPU-bound (aggregaciones complejas, joins en memoria) ven mejoras menores: el cuello de botella ya no era el disco.
El parámetro io_method
AIO está habilitado por defecto en PG 18. El nuevo parámetro io_method acepta dos valores: worker (usa procesos de background para I/O, compatible con cualquier sistema operativo) e io_uring (usa la interfaz io_uring de Linux 5.1+ para I/O asíncrono real en el kernel, el de mayor performance). Para producción en Linux moderno, io_method = io_uring es la configuración recomendada.
Consecuencia práctica para infraestructura: si los contenedores de producción corren kernels anteriores a 5.1 o tienen un perfil de seccomp que bloquea la syscall io_uring, hay que actualizar esa configuración antes de migrar. El modo worker sigue siendo la alternativa funcional y más rápida que PG 17.
Columnas generadas virtuales: menos almacenamiento, misma potencia
PostgreSQL 12 introdujo columnas generadas con GENERATED ALWAYS AS ... STORED: se calcula un valor derivado y se guarda físicamente en cada fila. Útiles, pero con un costo real en espacio de disco.
PostgreSQL 18 agrega las columnas generadas virtuales: se declaran igual pero sin STORED. El valor se calcula al vuelo en cada query que las referencia. No ocupan espacio en el heap de la tabla.
ALTER TABLE productos
ADD COLUMN precio_con_iva NUMERIC
GENERATED ALWAYS AS (precio_neto * 1.19) VIRTUAL;La diferencia práctica entre los dos tipos:
| Tipo | Almacenamiento en disco | CPU en lectura | CPU en escritura |
|---|---|---|---|
| STORED (PG 12+) | Sí, una columna por fila | Bajo (ya calculado) | Mayor (calcula y persiste) |
| VIRTUAL (PG 18) | No | Mayor (calcula en cada SELECT) | Bajo (no persiste) |
Cuándo elegir cada tipo:
- STORED: columnas que se filtran frecuentemente en
WHERE, se usan enJOINo se indexan. El dato precalculado justifica el almacenamiento. - VIRTUAL: columnas usadas principalmente en
SELECTde presentación, rara vez en filtros. Ideal para cálculos derivados en tablas de alto volumen (precios con impuestos, comisiones, conversiones de moneda).
Para bases de datos de facturación, reportería o ERP donde hay docenas de columnas derivadas de valor de negocio que se usan en vistas y reportes, las columnas virtuales simplifican el modelo de datos sin inflar el tamaño de las tablas. Esto es relevante especialmente cuando los sistemas de software a medida manejan tablas con millones de filas donde cada byte de overhead por fila suma.
OAuth 2.0 nativo: autenticación sin proxies adicionales
Antes de PG 18, conectar una base de datos a un sistema de identidad corporativo (Okta, Azure AD, Google Workspace, Keycloak) requería un proxy externo o configuraciones complejas de pgBouncer con autenticación delegada. Era fricción arquitectónica real para organizaciones que quieren centralizar la gestión de credenciales.
PostgreSQL 18 implementa OAUTHBEARER (RFC 7628) directamente en el motor. Los clientes pueden autenticarse presentando un token JWT emitido por el identity provider. PostgreSQL valida el token contra el endpoint JWKS configurado en pg_hba.conf:
host mi_bd all 0.0.0.0/0 oauth issuer="https://login.microsoftonline.com/tenant/v2.0" scope="postgres"Lo que esto cambia en la arquitectura de acceso
- SSO real para la base de datos: el mismo token que un servicio usa para llamar a una API interna puede usarse para conectarse a PostgreSQL.
- Rotación automática de credenciales: no hay passwords de base de datos que rotar manualmente; el ciclo de vida lo gestiona el identity provider.
- Auditoría de acceso centralizada: quién se conectó, cuándo y desde qué aplicación queda registrado en el sistema de identidad, no solo en los logs de PostgreSQL.
Para empresas con cumplimiento regulatorio bajo la Ley 21.719 de protección de datos personales en Chile, esta capacidad simplifica significativamente los controles de acceso sin dependencia de soluciones de terceros.
MERGE con RETURNING y otras mejoras SQL
PostgreSQL 15 introdujo la sentencia MERGE (ANSI SQL:2003). En versiones 16 y 17 fue refinada. PG 18 agrega la cláusula RETURNING a MERGE, que faltaba y obligaba a usar CTEs para capturar qué filas fueron insertadas, actualizadas o eliminadas:
MERGE INTO inventario AS inv
USING pedidos_nuevos AS p ON inv.sku = p.sku
WHEN MATCHED THEN
UPDATE SET stock = inv.stock - p.cantidad
WHEN NOT MATCHED THEN
INSERT (sku, stock) VALUES (p.sku, -p.cantidad)
RETURNING inv.sku, inv.stock, xmax::text::int > 0 AS fue_actualizado;Antes de PG 18, capturar el resultado del MERGE requería un workaround con CTE + SELECT adicional, lo que introducía una race condition potencial entre la operación y la lectura del resultado. Ahora es una sola operación atómica.
Otras mejoras SQL en PG 18
SKIP LOCKEDen más contextos: ahora disponible con cursores de referencia y en subqueries, útil para colas de trabajo distribuidas sin bloqueos.- Mejoras en jsonpath: soporte para
.datetime()sin casteo explícito previo. pg_dumpcon paralelismo mejorado: la opción-j(jobs paralelos) es más eficiente en bases de datos con muchos objetos pequeños.string_to_table()más flexible: mejor manejo de delimitadores complejos en funciones de string.
Rendimiento en producción: qué esperar
Los benchmarks publicados por el equipo de PostgreSQL y validados por la comunidad muestran los siguientes rangos en hardware con NVMe (AMD EPYC 7443, 256 GB RAM, Samsung 990 Pro 4 TB, Ubuntu 24.04, kernel 6.8):
| Workload | PG 17 | PG 18 (io_uring) | Diferencia |
|---|---|---|---|
| Sequential scan en tabla 50 GB | 1,8 GB/s | 3,1 GB/s | +72% |
| Escrituras concurrentes (32 workers) | ~42.000 TPS | ~58.000 TPS | +38% |
| Checkpoint en base de 100 GB | 4,2 min | 2,9 min | −31% |
| OLTP mixto (pgbench -j 16) | ~95.000 TPS | ~112.000 TPS | +18% |
| Cold query sobre tabla 8 GB sin caché | 11,2 s | 4,8 s | −57% |
El improvement en OLTP mixto (+18%) es más modesto porque ese workload es mayoritariamente CPU-bound. El beneficio real de AIO se concentra donde el disco era el cuello de botella: scans grandes, checkpoints y queries con datos que exceden el shared_buffers.
Implicancias para la arquitectura de tu sistema
Para equipos que diseñan sistemas de software a medida, PG 18 abre decisiones de arquitectura que antes no eran viables:
1. Shared_buffers más agresivo
Con I/O asíncrono, PostgreSQL puede aprovechar mejor su propio caché de páginas sin depender tanto del page cache del sistema operativo. La recomendación histórica de “25% de RAM para shared_buffers” puede revisarse hacia arriba en instancias dedicadas exclusivamente a PostgreSQL.
2. Menor presión por capas de caché intermedias
El patrón “cargar la tabla de configuración en Redis para evitar I/O de la base de datos” se vuelve menos necesario cuando el acceso a disco es más rápido y el prefetch más inteligente. Para bases de datos de configuración de tamaño moderado (< 1 GB), puede eliminarse la capa de caché intermedia y simplificar el stack.
3. Revisión de estrategia de índices
Las columnas generadas virtuales permiten definir índices sobre valores calculados sin duplicar datos en la tabla. El clásico índice funcional sobre LOWER(email) para búsquedas case-insensitive puede modelarse ahora con una columna virtual indexada, lo que hace el esquema más autodocumentado.
4. Gestión de acceso simplificada
Para aplicaciones con múltiples servicios que se conectan a la misma base de datos, OAuth 2.0 nativo permite asignar identidades de servicio individuales en lugar de compartir credenciales. Esto mejora la trazabilidad de auditoría y el principio de mínimo privilegio sin infraestructura adicional.
¿Cuándo migrar a PostgreSQL 18?
La migración desde PG 17 a PG 18 es más directa que saltos de versiones anteriores. No hay cambios en el formato de archivos de heap ni en el protocolo de wire. El proceso estándar es:
- Levantar una instancia PG 18 en paralelo con la instancia actual (mismo hardware o equivalente)
- Ejecutar
pg_upgradecon modo--linkpara migración sin copia completa de datos - Correr pruebas de regresión de queries, especialmente sobre MERGE, columnas generadas y autenticación
- Ajustar configuración: evaluar si
io_method = io_uringestá disponible en el kernel del servidor - Monitorear por 2-4 semanas antes de deshabilitar el rollback
Casos donde la migración tiene fricción adicional:
- Kernels Linux anteriores a 5.1 (sin
io_uring): quedan enio_method = worker, con mejora menor - Extensiones con hooks internos del storage manager: verificar compatibilidad con PG 18 antes de comenzar
- Contenedores con perfil de seccomp restrictivo: ajustar para permitir la syscall
io_uring - AWS RDS y servicios gestionados: el parámetro
io_methodpuede no ser configurable directamente; verificar disponibilidad de PG 18 en el proveedor
Para bases de datos en producción con mantenimiento evolutivo activo, la ventana recomendada es un trimestre con carga baja, con al menos un ciclo completo de testing en staging antes del cutover a producción.
¿Cuándo esperar para migrar?
Si la base de datos tiene menos de 20 GB, workload OLTP pequeño y está bien tuneada, el salto no es urgente. La arquitectura ya es probablemente CPU-bound y el beneficio de AIO será marginal. Para bases de datos de más de 50 GB con carga analítica, alto volumen de escrituras concurrentes o checkpoints lentos, el retorno técnico es claro y justifica la migración en 2026.
Conclusión
PostgreSQL 18 no es una actualización incremental de features: el I/O asíncrono representa un cambio estructural en cómo el motor interactúa con el almacenamiento moderno. Las columnas generadas virtuales, MERGE con RETURNING y OAuth 2.0 son adiciones concretas que simplifican patrones que antes requerían workarounds o infraestructura adicional.
Para equipos que corren bases de datos grandes con carga analítica o escrituras concurrentes, la migración tiene un retorno técnico real. Para bases de datos OLTP de menor tamaño ya bien optimizadas, el salto es menos urgente pero vale planificarlo para el año.
Si tu empresa está evaluando una migración de base de datos, una modernización de arquitectura de datos, o necesita un diagnóstico técnico del stack actual, conversemos sin compromiso. En Codelan hacemos un diagnóstico gratuito y entregamos una recomendación concreta para tu caso.
Preguntas frecuentes sobre PostgreSQL 18
¿PostgreSQL 18 es compatible con versiones anteriores a PG 17?
pg_upgrade soporta saltos de múltiples versiones y puede migrar desde PG 14, 15 o 16 directamente a PG 18 sin reescribir los datos. El formato de archivos de heap y WAL cambia entre versiones mayores, pero pg_upgrade en modo --link hace la transición sin duplicar los datos en disco. Lo importante es verificar la compatibilidad de extensiones de terceros antes de comenzar.
¿io_uring es seguro para producción en 2026?
Sí, en Linux 5.15 LTS, 6.1 LTS o 6.6 LTS con los parches de seguridad al día. io_uring tuvo varias CVEs entre 2022 y 2023, pero los parches están bien establecidos en los kernels de soporte largo actuales. Distribuciones como Ubuntu 22.04 LTS, Debian 12 o RHEL 9 incluyen todos los parches relevantes. Si hay dudas, io_method = worker entrega la mayoría de los beneficios AIO con un mecanismo más conservador.
¿Las columnas generadas virtuales se pueden indexar?
Sí. Se puede crear un índice sobre una columna virtual igual que sobre una columna regular. El índice almacena los valores calculados, de modo que su tamaño equivale al de un índice sobre una columna almacenada. La diferencia es que la tabla no guarda el valor, solo el índice. Esto es útil para búsquedas frecuentes sobre valores derivados sin duplicar datos en el heap de la tabla.
¿OAuth 2.0 es compatible con todos los identity providers?
OAUTHBEARER en PG 18 sigue el estándar RFC 7628 y es compatible con cualquier proveedor que emita tokens JWT con un endpoint JWKS público: Okta, Azure AD, Google, Keycloak, Auth0, entre otros. La configuración requiere especificar el issuer y el scope esperado en pg_hba.conf. El identity provider debe incluir el claim de usuario en el token (por convención, el claim sub o un claim configurable).
¿Qué extensiones debo verificar antes de migrar?
Las extensiones que más frecuentemente presentan problemas de compatibilidad entre versiones mayores son: PostGIS (verificar versión compatible con PG 18), TimescaleDB (tiene sus propias notas de migración), Citus (distribución horizontal), pgvector (vectores para búsqueda semántica IA — muy usada en 2026) y cualquier extensión que use hooks internos del storage manager. Las extensiones puramente SQL (como pg_trgm, uuid-ossp, hstore o unaccent) son invariablemente compatibles.
¿El beneficio de rendimiento aplica también en bases de datos en la nube?
Depende del proveedor y del servicio. En instancias EC2 con almacenamiento NVMe o en servidores dedicados, el beneficio de AIO es completo. En AWS RDS PostgreSQL, el control sobre io_method puede ser limitado — el servicio gestionado expone un subconjunto de parámetros de configuración. Para obtener el máximo beneficio de PG 18 en producción cloud, las opciones más directas son RDS Custom, instancias auto-gestionadas en EC2 o servidores dedicados en datacenter.
