PostgreSQL 18: async I/O y skip scan, qué prender en producción

PostgreSQL 18 salió como versión estable el 25 de septiembre de 2025 y hoy ya va por su cuarta actualización menor, 18.4. Eso importa por una razón práctica: la rama dejó de ser "lo nuevo que hay que mirar de reojo" y pasó a ser "lo que ya podés poner en producción". Y trae dos cambios que tocan directamente el rendimiento de tus consultas sin que reescribas una sola línea de SQL: el async I/O nativo y el skip scan en índices B-tree. Vamos a lo concreto.

PostgreSQL 18 es la versión mayor del sistema de base de datos relacional de código abierto, publicada en septiembre de 2025 por el PostgreSQL Global Development Group. Sus dos features de rendimiento más relevantes son el subsistema de I/O asincrónico (async I/O), que solapa el acceso a disco con el procesamiento, y el skip scan de índices B-tree, que permite usar índices multicolumna aunque la consulta no filtre por la primera columna. Ambas mejoran la velocidad sin cambiar el código de la aplicación.

¿Qué cambió en PostgreSQL 18 respecto de la versión anterior?

Cambió sobre todo cómo Postgres lee del disco y cómo aprovecha los índices que ya tenés. Según Crunchy Data, PostgreSQL 18 llegó con más de 3.000 commits de más de 200 colaboradores, pero el grueso del impacto para un desarrollador se concentra en un puñado de features. Estas son las que más rinden en el día a día:

• Async I/O nativo: Postgres puede encolar varias lecturas a disco en paralelo en lugar de esperar una por una, lo que acelera sequential scans, bitmap heap scans y VACUUM.
• Skip scan en B-tree: un índice de varias columnas ahora sirve aunque la consulta no restrinja la primera columna, algo que antes obligaba a mantener índices duplicados.
• UUIDv7 nativo: identificadores con prefijo de timestamp que mejoran la localidad de los índices frente al UUIDv4 aleatorio.
• Columnas generadas VIRTUAL por defecto: se calculan al vuelo en vez de escribirse a disco (con la contra de que no se pueden indexar).
• Autenticación OAuth 2.0: tokens bearer contra proveedores de identidad externos, configurable en pg_hba.conf.

Este artículo se concentra en las dos primeras, que son las que cambian el perfil de rendimiento de una base existente sin migración de datos.

¿Qué es el async I/O nativo de PostgreSQL 18 y para qué sirve?

El async I/O es un subsistema que permite a PostgreSQL 18 pedir varias lecturas a disco de forma anticipada y en paralelo, en lugar de bloquearse esperando cada una. Hasta la versión anterior, la I/O era sincrónica: como resume Crunchy Data, "cada request individual al disco se esperaba hasta completarse antes de pasar a lo siguiente". Ahora esas lecturas se solapan con el procesamiento, y en operaciones que barren mucho disco eso se traduce en menos tiempo muerto esperando.

Se controla con el parámetro io_method, que acepta tres valores:

• worker (por defecto): usa procesos de trabajo dedicados a la I/O. Arranca con 3 workers, ajustables con io_workers. Funciona en cualquier plataforma soportada.
• io_uring: aprovecha la interfaz io_uring del kernel de Linux (5.1+) desde los propios procesos backend, sin workers separados. Requiere que Postgres se haya compilado con soporte para io_uring.
• sync: el comportamiento clásico sincrónico, por si necesitás volver atrás.

Las operaciones que más se benefician son las que leen bloques de forma predecible: sequential scans, bitmap heap scans y VACUUM. Según las notas de versión oficiales de PostgreSQL 18, el nuevo subsistema mejora el rendimiento de esas operaciones al permitir que el motor tenga varias lecturas "en vuelo" al mismo tiempo. La ganancia real depende de tu hardware y de si el dato está en caché o hay que ir al disco: en storage rápido con io_uring el efecto es notable; en una base que entra entera en RAM, casi no lo vas a ver.

¿Qué es el skip scan en índices B-tree y cuándo lo usás?

El skip scan permite que un índice B-tree multicolumna se use aunque la consulta no filtre por su primera columna. Antes, un índice sobre (region, category, date) quedaba inutilizado si consultabas solo por category y date: el planner se iba a un sequential scan. Con skip scan, PostgreSQL 18 identifica los valores distintos de la columna omitida y hace un scan dirigido por cada uno, "saltando" las partes del índice que no aplican.

Dónde brilla y dónde no:

• Ideal con baja cardinalidad en las columnas líderes: si la primera columna tiene pocos valores distintos (por ejemplo 3 a 5 estados), el skip recorre pocos prefijos y vuela.
• Necesita condiciones de igualdad en las columnas posteriores: el patrón típico es "sin restricción en la primera columna + igualdad en una columna más adentro".
• Se degrada con alta cardinalidad en la columna líder: si el prefijo tiene millones de valores distintos, saltar deja de compensar y el planner puede preferir bitmap o sequential scan.
• Sirve para consolidar índices: en cargas analíticas donde combinás columnas de formas distintas, a veces reemplazás dos o tres índices por uno solo.

La mejor parte: no hay nada que configurar ni reescribir. El planner decide solo si el skip scan conviene. Un ejemplo publicado por pgEdge lo muestra bien: con un índice sobre (region, product_category, sale_date) y una consulta que filtra por product_category y sale_date (sin tocar region), la misma query pasó de 48,5 ms con sequential scan en Postgres 17 a 12,8 ms con skip scan en Postgres 18 —un ~4× más rápido y con muchas menos lecturas de buffers—. Las notas oficiales van más allá y señalan que, con un prefijo de baja cardinalidad, un skip scan puede ser "multiple orders of magnitude" (varios órdenes de magnitud) más rápido que el scan completo equivalente.

¿Qué gana un proyecto en producción con estas dos features?

Gana rendimiento sin refactor y sin migración de datos, que es exactamente lo que hace atractiva la actualización. Estos son los efectos prácticos:

• Reportes y analítica más rápidos: el skip scan rescata índices multicolumna que hoy ignorás, especialmente en tablas con columnas de estado, región o tipo.
• Menos presión sobre el disco en barridos grandes: el async I/O acorta VACUUM y scans pesados, que suelen ser los que te comen la ventana nocturna de mantenimiento.
• Posible reducción de índices: si tenías índices espejados solo para cubrir combinaciones de columnas, quizás elimines algunos y bajes el costo de escritura.
• Cero cambios en el código de la app: ambas features actúan a nivel del motor; tu SQL sigue igual.

La contracara honesta: no es magia. El async I/O luce en storage con latencia real, no en bases que entran en RAM; y el skip scan puede no elegirse si el prefijo del índice tiene alta cardinalidad. Medí tu caso con EXPLAIN (ANALYZE, BUFFERS) antes y después, en vez de asumir la mejora.

¿Cómo probás async I/O y skip scan hoy?

Podés probar las dos en un entorno de staging con PostgreSQL 18 en pocos pasos, sin tocar tu base de producción. La rama ya está madura —según endoflife.date, 18.4 es la última menor (mayo de 2026) y la rama 18 tiene soporte hasta noviembre de 2030— así que estás actualizando a algo estable, no a un beta.

1. Levantá un Postgres 18 de prueba: instalá 18.4 en un servidor de staging o en un contenedor y restaurá ahí un dump de tu base real para medir con datos representativos.
2. Elegí el método de I/O: revisá el valor actual con SHOW io_method;. En Linux con kernel 5.1+, probá io_uring en postgresql.conf (io_method = io_uring) y reiniciá; si no, quedate en worker y tuneá io_workers.
3. Verificá el skip scan: no requiere configuración. Tomá una consulta que filtre por columnas intermedias de un índice multicolumna y corré EXPLAIN (ANALYZE, BUFFERS); buscá que el plan use el índice en vez de un Seq Scan.
4. Compará contra tu versión actual: corré el mismo EXPLAIN (ANALYZE, BUFFERS) en tu Postgres viejo y en el 18 para ver el delta de tiempo y de buffers leídos.

Un detalle que baja el riesgo de actualizar: dentro de la rama 18, pasar de una menor a otra (18.0 → 18.4) no requiere dump/restore, según las notas de las versiones menores del proyecto. El salto que sí exige planificación es el de una versión mayor anterior a la 18, donde conviene usar pg_upgrade y una ventana controlada.

Si estás armando la parte de respaldo antes de migrar, te sirven las notas del blog sobre backups lógicos de PostgreSQL con pg_dump y su verificación; y si tu caso es búsqueda semántica, la nota sobre pgvector en PostgreSQL complementa bien este panorama de la versión 18.

Preguntas frecuentes

¿Cuándo salió PostgreSQL 18?

PostgreSQL 18 se publicó como versión estable el 25 de septiembre de 2025. La última actualización menor disponible es la 18.4, de mayo de 2026, y la rama recibe soporte hasta noviembre de 2030 según endoflife.date.

¿Tengo que reescribir mis consultas para usar el skip scan?

No. El skip scan lo decide el planificador de consultas de forma automática; tu SQL no cambia. Solo tenés que estar en PostgreSQL 18 y tener un índice B-tree multicolumna que la consulta pueda aprovechar.

¿Qué necesito para usar io_uring en el async I/O?

Necesitás Linux con kernel 5.1 o superior y un PostgreSQL 18 compilado con soporte para io_uring. Se activa poniendo io_method = io_uring en postgresql.conf y reiniciando. Si no lo tenés, el método por defecto worker funciona en cualquier plataforma soportada.

¿El async I/O mejora el rendimiento en cualquier caso?

No siempre. El async I/O luce cuando hay que ir al disco de verdad en operaciones como sequential scans, bitmap heap scans y VACUUM. Si tu base entra completa en memoria, la mejora es marginal. Medí con EXPLAIN (ANALYZE, BUFFERS) en tu propio entorno.

¿Actualizar de una versión anterior a PostgreSQL 18 requiere migrar los datos?

Sí, un salto de versión mayor (por ejemplo de 16 o 17 a 18) requiere pg_upgrade o dump/restore y una ventana de mantenimiento. En cambio, moverte entre versiones menores dentro de la rama 18 (18.0 a 18.4) no requiere dump/restore.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting