PostgreSQL 18: I/O asíncrono y skip scan a fondo

Durante años, la regla para acelerar una base de datos PostgreSQL que se quedaba corta fue casi siempre la misma: tirale más fierro. Más CPU, más RAM, discos más rápidos. PostgreSQL 18 rompe parcialmente esa lógica con dos cambios de fondo en cómo lee los datos —un subsistema de I/O asíncrono y el skip scan en índices B-tree— que, en cargas de lectura intensiva, pueden mejorar el rendimiento de forma significativa sin que toques una sola línea de tu plan de servidor.

PostgreSQL 18 es la versión mayor actual del motor de bases de datos relacional open source, publicada en septiembre de 2025 por el PostgreSQL Global Development Group. Su novedad central es un subsistema de I/O asíncrono (AIO) que permite emitir varias lecturas de disco en paralelo en lugar de esperar una por una, más el "skip scan" en índices B-tree multicolumna. Juntos aceleran lecturas, vacuums y consultas analíticas, especialmente en servidores cloud con almacenamiento de red.

¿Por qué se habla tanto de PostgreSQL 18 ahora?

PostgreSQL 18: I/O asíncrono y skip scan aceleran tu Cloud Server

Porque ya no es una promesa beta: es la rama estable que estás (o deberías estar) corriendo en producción. La última versión de mantenimiento, PostgreSQL 18.4, salió el 14 de mayo de 2026 junto con las actualizaciones del resto de las ramas soportadas, así que la 18 ya pasó por varios ciclos de corrección de bugs y endurecimiento. Eso la vuelve una candidata realista para migrar, no un experimento de laboratorio.

Lo que mantiene el tema vivo en Hacker News, en los blogs de la comunidad y en los benchmarks que circulan es el I/O asíncrono. Es el cambio arquitectónico más profundo del motor en años, y como toca el camino crítico de lectura de cada consulta, todo el mundo está midiendo cuánto rinde de verdad en su carga real. Spoiler: rinde, pero no es magia automática.

¿Qué es el I/O asíncrono de PostgreSQL 18 y de dónde viene?

Hasta PostgreSQL 17, cuando un backend necesitaba leer una página que no estaba en memoria, pedía ese bloque al sistema operativo y se quedaba bloqueado esperando a que el disco respondiera. Una lectura, una espera, la siguiente lectura. En un disco local rapidísimo eso se nota poco; en el almacenamiento de red típico de un entorno cloud, donde cada lectura suma latencia, esas esperas se acumulan y matan el throughput.

El nuevo subsistema AIO cambia el modelo: ahora PostgreSQL puede encolar varias lecturas a la vez y seguir trabajando mientras el almacenamiento las resuelve en paralelo. Es una generalización del viejo readahead, y beneficia directamente a las operaciones que más leen del disco:

Sequential scans: recorridos completos de tabla, el pan de cada día de los reportes y agregaciones.
Bitmap heap scans: el patrón que usa el planner cuando combina varios índices.
VACUUM: el mantenimiento que evita el bloat y mantena sanas tus tablas.

Según el análisis técnico de la comunidad, sobre Linux y usando io_uring esto puede traducirse en mejoras de hasta 2-3x en cargas de lectura intensiva. De ahí sale el "hasta 3x" del título: es un techo realista para workloads dominados por lectura desde almacenamiento de red, no un número garantizado para cualquier consulta.

¿Cómo se configura el I/O asíncrono? Los tres modos de io_method

El comportamiento se controla con un solo parámetro, io_method, que admite tres valores:

worker (el default): procesos de I/O dedicados en segundo plano buscan los datos por su cuenta mientras tu consulta sigue. Funciona en cualquier plataforma y es el que viene activado de fábrica.
io_uring: usa la interfaz io_uring del kernel de Linux para I/O asíncrono real mediante un ring buffer compartido con el kernel, sin procesos worker intermedios. Requiere que PostgreSQL se haya compilado con --with-liburing y un kernel compatible.
sync: replica el comportamiento síncrono y bloqueante de PostgreSQL 17. Es la red de seguridad si algo se comporta raro.

-- Ver el modo activo
SHOW io_method;

-- Cambiarlo (requiere reinicio del servidor)
ALTER SYSTEM SET io_method = 'worker';
-- o, en Linux con liburing disponible:
ALTER SYSTEM SET io_method = 'io_uring';

Un detalle clave que aparece en los benchmarks y que conviene grabarse: io_uring no siempre gana. Las pruebas públicas que compararon PostgreSQL 17 contra 18 mostraron que el modo worker —el default— suele ser la opción más sólida en la práctica, y que io_uring puede incluso quedar por detrás en ciertos niveles de concurrencia y tipos de almacenamiento. La diferencia depende mucho de si corrés sobre NVMe local o sobre almacenamiento de red. Moraleja: no cambies el default a ciegas; medí tu caso.

¿Qué es el skip scan y qué problema resuelve?

El segundo gran cambio es más quirúrgico pero igual de útil en el día a día. Tiene que ver con los índices B-tree de varias columnas.

Hasta ahora, un índice multicolumna sobre, digamos, (pais, ciudad) solo se podía usar bien si tu consulta filtraba por la primera columna. Si buscabas únicamente por ciudad, sin condición sobre pais, PostgreSQL muchas veces descartaba el índice y se iba a un sequential scan completo. La famosa "limitación de la columna más a la izquierda".

El skip scan de PostgreSQL 18 levanta esa restricción. Ahora el motor puede recorrer internamente los valores distintos de las columnas líderes que no estás filtrando, y para cada uno "bucear" en el índice buscando coincidencias en las columnas posteriores. El planner decide automáticamente cuándo el skip scan conviene frente a un scan secuencial. ¿El resultado concreto?

Menos índices redundantes: dejás de necesitar índices extra solo para cubrir consultas que omiten la primera columna.
Consultas que antes hacían seq scan ahora usan el índice: con el consiguiente ahorro de I/O y CPU.
Cero cambios en tu código: es transparente; el planner lo aplica solo cuando rinde.

¿Qué implica esto para un proyecto en producción?

La implicancia más interesante es económica además de técnica. Si tu cuello de botella era la latencia de lectura —reportes lentos, dashboards que tardan, jobs de mantenimiento que se eternizan— hay una porción de ese problema que antes solo se resolvía escalando el servidor y que ahora podés atacar con una actualización de versión. En un cluster sobre un Cloud Server, donde el almacenamiento es de red y la latencia por lectura pesa, ese es justo el escenario donde el AIO más se nota.

Ahora bien, seamos honestos con las expectativas:

No toda carga mejora 3x: el techo de 2-3x es para lectura intensiva desde almacenamiento de red. Una carga OLTP con todo en RAM o dominada por escrituras va a ver mucho menos.
El default ya te da casi todo: el modo worker aporta el grueso de la mejora sin que toques nada raro.
Medir no es opcional: sin un benchmark de tu consulta sobre tu almacenamiento, cualquier número es prestado.

¿Qué podés hacer con esto hoy?

Si ya estás en PostgreSQL 18, no tenés que hacer nada para empezar a aprovecharlo: el I/O asíncrono en modo worker y el skip scan vienen activos. Pero podés sacarle más jugo con tres pasos concretos:

Confirmá tu versión y tu modo de I/O. Con SELECT version(); y SHOW io_method; sabés desde dónde partís.
Verificá si el skip scan se está usando. Corré EXPLAIN (ANALYZE, BUFFERS) sobre tus consultas que filtran por columnas no líderes de un índice multicolumna y mirá si el plan ahora usa el índice en vez de un Seq Scan.
Probá io_uring solo si medís beneficio. Si corrés sobre Linux con un kernel reciente y una build con --with-liburing, hacé un benchmark A/B contra worker con tu carga real antes de cambiarlo en producción.

-- ¿Mi consulta aprovecha el índice multicolumna con skip scan?
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM ventas WHERE ciudad = 'Rosario';
-- Buscá un "Index Scan" / "Skip Scan" en lugar de "Seq Scan"

Si todavía estás en una versión anterior, este es buen momento para planificar la migración —y aprovechar para repasar tu estrategia de respaldo antes de tocar nada. Tenemos guías de backups de PostgreSQL con pgBackRest y de backups con Restic en Ubuntu que conviene leer como complemento: actualizar el motor sin un backup probado es jugar con fuego.

Preguntas frecuentes

¿Necesito recompilar o reconvertir mis datos para usar el I/O asíncrono?

No. El subsistema AIO ya viene en PostgreSQL 18 y el modo por defecto (worker) funciona en cualquier plataforma sin compilar nada especial. Solo el modo io_uring requiere una build con --with-liburing y un kernel Linux compatible.

¿El skip scan reemplaza a mis índices actuales?

No los reemplaza: hace que tus índices B-tree multicolumna existentes sirvan en más consultas, incluso cuando no filtrás por la primera columna. En la práctica esto puede dejar obsoletos algunos índices que creaste solo para cubrir esos casos, pero confirmalo con EXPLAIN antes de borrar nada.

¿De verdad voy a ver 3x de mejora en mi cluster?

Depende de tu carga. El rango de 2-3x corresponde a workloads de lectura intensiva sobre almacenamiento de red en Linux. Cargas dominadas por escritura o con todo el dataset en memoria van a ver mejoras mucho más modestas. La única respuesta confiable sale de medir tu caso con EXPLAIN (ANALYZE, BUFFERS) y un benchmark representativo.

¿Conviene activar io_uring en lugar del modo worker por defecto?

No por defecto. Los benchmarks públicos muestran que el modo worker suele ser la opción más sólida y que io_uring a veces rinde menos según la concurrencia y el tipo de disco. Cambialo solo si una prueba A/B con tu carga real demuestra una mejora clara.

¿Cuál es la última versión estable de PostgreSQL 18?

Al momento de escribir esta nota, la última versión de mantenimiento es PostgreSQL 18.4, publicada el 14 de mayo de 2026. Verificá siempre la versión vigente en el sitio oficial del proyecto, porque las ramas reciben actualizaciones de seguridad de forma periódica.

El cambio de mentalidad

PostgreSQL 18 no es una de esas releases de "features para el changelog". El I/O asíncrono ataca el supuesto más viejo del motor —que leer del disco es esperar— y el skip scan elimina una limitación que obligaba a inflar el esquema con índices de más. Para quien corre bases de datos en un Cloud Server, la lección es concreta: antes de escalar el hardware, revisá si una actualización de versión bien medida ya te resuelve el problema. Muchas veces, la velocidad que buscás ya está en el software.

Fuentes: anuncio oficial de PostgreSQL 18, análisis del I/O asíncrono de pganalyze y explicación del skip scan de pgEdge.