⏱️ Lectura: 9 min
PostgreSQL 18 ya está disponible y trae uno de los cambios de arquitectura más importantes de los últimos años: un subsistema de entrada/salida asíncrona que promete acelerar las consultas que dependen de lecturas de disco. A esto se suman mejoras en índices, seguridad y generación de identificadores únicos.
📑 En este artículo
La nueva versión mantiene la cadencia anual del proyecto y llega con soporte oficial hasta noviembre de 2030, consolidando funciones que la comunidad pedía desde hace varias versiones.
TL;DR
- PostgreSQL 18 se liberó el 25 de septiembre de 2025, con soporte oficial hasta noviembre de 2030.
- Incorpora un subsistema de entrada/salida asíncrona (AIO) configurable con el parámetro io_method (sync, worker, io_uring).
- Los índices B-tree ahora soportan “skip scan” en consultas multicolumna que no filtran por la primera columna.
- Se agrega la función uuidv7(), que genera identificadores UUID ordenables por tiempo de creación.
- Las columnas generadas pueden crearse como VIRTUAL en lugar de STORED, ahorrando espacio en disco.
- libpq suma autenticación OAuth 2.0 para conexiones cliente-servidor más seguras.
- EXPLAIN muestra el uso de buffers por defecto, sin necesidad de agregar la opción BUFFERS manualmente.
- Los slots de replicación lógica ahora pueden sincronizarse hacia servidores en standby físico.
Qué pasó
El equipo de desarrollo de PostgreSQL liberó la versión 18 el 25 de septiembre de 2025, tras un ciclo de desarrollo de aproximadamente un año, el mismo ritmo anual que el proyecto mantiene desde 2018. Como en cada lanzamiento mayor, PostgreSQL 18 no es una actualización cosmética: toca el motor de almacenamiento, el planificador de consultas y la capa de autenticación.
La novedad más comentada es el nuevo subsistema de entrada/salida asíncrona, conocido como AIO (Asynchronous I/O). Hasta la versión 17, cada proceso backend de PostgreSQL emitía una operación de lectura de disco y esperaba a que el sistema operativo la completara antes de continuar. Con AIO, el servidor puede emitir múltiples solicitudes de lectura en paralelo y seguir trabajando mientras el sistema operativo las resuelve, lo que reduce el tiempo ocioso en operaciones como sequential scans, bitmap heap scans y VACUUM.
El comportamiento del subsistema se controla con el parámetro io_method, que admite tres valores: sync (el comportamiento clásico, sin cambios), worker (un pool de procesos dedicados a resolver operaciones de E/S) e io_uring, que aprovecha la interfaz de Linux del mismo nombre para lograr la menor sobrecarga posible.
-- Ver el metodo de E/S asincrona configurado
SHOW io_method;
-- Cambiarlo (requiere reinicio del servidor)
ALTER SYSTEM SET io_method = 'io_uring';Otra mejora relevante en el planificador es el “skip scan” para índices B-tree multicolumna. Antes de PostgreSQL 18, un índice sobre las columnas (pais, ciudad) solo se usaba de forma eficiente si la consulta filtraba por pais. A partir de esta versión, el planificador puede “saltar” entre los distintos valores de la primera columna internamente y seguir usando el índice aunque la consulta filtre únicamente por ciudad.
Contexto e historia
PostgreSQL adoptó un calendario de lanzamientos anuales desde la versión 10, publicada en 2017. Desde entonces cada versión mayor llega en septiembre u octubre y recibe cinco años de soporte con parches de seguridad y correcciones de errores, sin agregar funciones nuevas fuera del lanzamiento anual.
El trabajo sobre entrada/salida asíncrona no es nuevo: distintos colaboradores del proyecto, entre ellos Andres Freund —conocido también por haber detectado la puerta trasera en xz-utils en 2024—, llevaban varios ciclos de desarrollo trabajando en versiones preliminares de AIO que no llegaron a integrarse por falta de consenso sobre la arquitectura. PostgreSQL 18 es la primera versión donde ese trabajo se consolida en el núcleo del motor.
Versiones anteriores fueron sentando las bases para este cambio: PostgreSQL 16 mejoró la paralelización de consultas y la replicación lógica, y PostgreSQL 17 introdujo el respaldo incremental (incremental backup) con pg_basebackup, además de mejoras de rendimiento en VACUUM. PostgreSQL 18 continúa esa línea centrada en el motor de almacenamiento más que en funciones de superficie.
Datos y cifras
Según las notas de lanzamiento oficiales, PostgreSQL 18 integra el trabajo de cientos de colaboradores y decenas de “committers” reconocidos por el proyecto, siguiendo el mismo modelo de desarrollo abierto y descentralizado que sostiene el proyecto desde su creación en 1996 (como continuación de POSTGRES, iniciado en la Universidad de California, Berkeley, en 1986).
El propio calendario de soporte es un dato clave para equipos de infraestructura: PostgreSQL 18 recibirá actualizaciones hasta noviembre de 2030, mientras que PostgreSQL 13, la versión mayor más antigua aún soportada al momento de este lanzamiento, sale de soporte en noviembre de 2025. Eso deja una ventana de solapamiento de apenas unas semanas para los equipos que todavía operan sobre versiones muy antiguas.
En cuanto al rendimiento, los primeros reportes de la comunidad sobre cargas intensivas en lectura de disco —bases de datos que no caben completas en memoria— muestran mejoras notables al pasar de io_method=sync a io_method=io_uring en Linux, aunque la magnitud exacta depende del tipo de almacenamiento (SSD NVMe versus almacenamiento en la nube) y del patrón de acceso de cada carga de trabajo.
Impacto y análisis
Para equipos que operan bases de datos propias, el impacto más directo de PostgreSQL 18 está en cargas de trabajo con mucha lectura de disco: reportes analíticos, tablas grandes con índices parciales, o instancias donde el conjunto de datos activo supera la memoria disponible. En esos escenarios, AIO puede traducirse en consultas más rápidas sin cambiar una sola línea de SQL, solo ajustando io_method.
El siguiente diagrama resume, de forma simplificada, cómo el planificador decide si una consulta necesita pasar por el subsistema de E/S asíncrona:
graph LR
A["Consulta SQL"] --> B["Planificador"]
B --> C{"Requiere leer bloques de disco?"}
C -->|"Si"| D["Subsistema AIO (io_method)"]
C -->|"No, esta en cache"| E["Resultado desde memoria"]
D --> F["Workers o io_uring"]
F --> G["Resultado devuelto al cliente"]
E --> G💡 Tip: El modo io_method=io_uring solo está disponible en Linux con un kernel reciente; en otros sistemas operativos PostgreSQL usa automáticamente el modo worker.
Para proveedores de bases de datos administradas, la adopción no es inmediata: servicios como Amazon RDS, Google Cloud SQL o Azure Database for PostgreSQL suelen tardar varios meses en ofrecer una versión mayor nueva, ya que necesitan validar compatibilidad con sus propias capas de gestión, monitoreo y respaldo. Eso significa que buena parte de los usuarios de PostgreSQL en la nube todavía no podrán probar PostgreSQL 18 en el corto plazo.
⚠️ Ojo: Antes de migrar a PostgreSQL 18, revisá las notas de compatibilidad: algunas extensiones de terceros necesitan recompilarse contra la nueva ABI del servidor, y el comportamiento por defecto de las columnas generadas cambió de STORED a VIRTUAL.
Ese último punto merece explicación aparte. Antes de esta versión, si se creaba una columna generada con GENERATED ALWAYS AS (...) sin especificar el modo, PostgreSQL asumía STORED (el valor calculado se guarda físicamente en disco). En PostgreSQL 18 el valor calculado por defecto pasa a ser VIRTUAL (se calcula en el momento de la lectura, sin ocupar espacio en disco), lo que puede sorprender a quienes migran scripts de esquema sin revisar el detalle.
-- Columna generada virtual (no ocupa espacio en disco)
CREATE TABLE pedidos (
precio numeric,
cantidad integer,
total numeric GENERATED ALWAYS AS (precio * cantidad) VIRTUAL
);
-- Generar un UUID ordenable por tiempo (nuevo en PostgreSQL 18)
SELECT uuidv7();Qué sigue
El proyecto ya trabaja en extender el subsistema de E/S asíncrona a más operaciones internas —hoy cubre principalmente lecturas secuenciales y bitmap scans— de cara a PostgreSQL 19, previsto para septiembre de 2026 siguiendo el mismo calendario anual. También se espera que continúe el debate sobre un pooler de conexiones integrado en el núcleo, una función que la comunidad pide desde hace años y que hoy sigue resolviéndose con herramientas externas como PgBouncer o PgCat.
En el corto plazo, lo más relevante para equipos de desarrollo es revisar el changelog completo antes de planificar una migración, especialmente si dependen de extensiones de terceros o de herramientas de replicación lógica, y evaluar en un entorno de pruebas si io_method=io_uring aporta una mejora medible en su carga de trabajo real antes de activarlo en producción.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Cuándo se lanzó PostgreSQL 18?
PostgreSQL 18 se liberó oficialmente el 25 de septiembre de 2025, siguiendo el calendario de lanzamientos anuales que el proyecto mantiene desde la versión 10.
¿Qué es el subsistema de E/S asíncrona (AIO)?
Es un nuevo mecanismo que permite al servidor emitir varias solicitudes de lectura de disco en paralelo en lugar de esperar a que cada una termine antes de emitir la siguiente, configurable con el parámetro io_method.
¿Qué es el “skip scan” en índices B-tree?
Es una técnica que permite usar un índice multicolumna de forma eficiente aunque la consulta no filtre por la primera columna del índice, algo que antes obligaba a recorrer la tabla completa o crear índices adicionales.
¿Qué ventaja tiene uuidv7() sobre gen_random_uuid()?
Los UUID versión 7 incluyen una marca de tiempo en sus primeros bits, por lo que quedan ordenados cronológicamente de forma natural, lo que mejora el rendimiento de los índices B-tree que los usan como clave primaria en comparación con los UUID versión 4, que son completamente aleatorios.
¿Es seguro migrar a PostgreSQL 18 de inmediato?
Depende del entorno: el proyecto recomienda probar la migración en un entorno de pruebas, revisar la compatibilidad de extensiones de terceros y el cambio de comportamiento por defecto en columnas generadas antes de mover cargas de producción.
¿Hasta cuándo tendrá soporte PostgreSQL 18?
Según la política de soporte del proyecto, PostgreSQL 18 recibirá parches de seguridad y corrección de errores hasta noviembre de 2030.
Referencias
- postgresql.org — Notas de lanzamiento oficiales de PostgreSQL 18.
- postgresql.org — Documentación completa de la versión 18.
- en.wikipedia.org — Historia y arquitectura general del proyecto PostgreSQL.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios