Postgres 18 está a punto de llegar con una innovación que cambiará radicalmente la forma en que las bases de datos PostgreSQL manejan las operaciones de lectura desde disco. La adopción de la entrada/salida asíncrona (E/S asíncrona) representa un giro significativo en la arquitectura del sistema, prometiendo mejoras notables en el rendimiento, particularmente en ambientes basados en la nube donde la latencia y el acceso a almacenamiento remoto son un desafío constante. Históricamente, PostgreSQL ha utilizado un modelo de E/S síncrona, en el que cada solicitud de lectura bloquea la ejecución hasta que el sistema operativo devuelve los datos requeridos. Este enfoque, aunque simple y efectivo en sistemas tradicionales, revela limitaciones críticas en la era actual de la computación en la nube. Cuando el almacenamiento está conectado en red, como sucede con los volúmenes Amazon EBS, los retardos pueden superar el milisegundo por operación, generando cuellos de botella y desperdiciando ciclos de CPU mientras la base de datos espera.
La E/S asíncrona rompe este modelo rígido al permitir que múltiples solicitudes de lectura se emitan simultáneamente, sin necesidad de esperar que una se complete antes de comenzar la siguiente. Esto optimiza el uso de la capacidad de banda y reduce el tiempo ocioso del procesador, creando una base para una respuesta mucho más rápida y escalable. Postgres 18, en su primera versión beta, ya revela implementaciones concretas de esta técnica, lo que denota años de desarrollo y una profunda reevaluación de su manejo interno de datos. Una de las grandes contribuciones que prepararon el terreno para esta evolución fueron las llamadas “read streams” introducidas en Postgres 17. Estas abstractions uniformaron cómo se gestionan las solicitudes de lectura internamente, además de utilizar posix_fadvise() como mecanismo para solicitar al sistema operativo una precarga de datos.
Sin embargo, esa precarga era una mera sugerencia para el kernel y no eliminaba la necesidad de realizar llamadas bloqueantes tradicionales para cada lectura. Postgres 18 va un paso más allá al eliminar esta dependencia, gestionando directamente la lectura de datos en los buffers compartidos de la base de datos y evitando la dependencia de heurísticas internas del kernel y variabilidad en su comportamiento. El núcleo de esta innovación se centra en el nuevo parámetro de configuración io_method, que determina el método concreto para manejar las operaciones de E/S. Este parámetro añade flexibilidad y control para adaptarse a diferentes entornos y requisitos de hardware. Las opciones incluyen un modo síncrono clásico, un modo basado en procesos workers de E/S y el uso de io_uring, una interfaz de alto rendimiento específica para Linux.
El modo sync replica el comportamiento tradicional. Aunque existe para compatibilidad, su implementación no mejora la eficiencia frente a versiones anteriores. Por otro lado, el modo worker emplea procesos dedicados que ejecutan las tareas de lectura en segundo plano, liberando al proceso principal para que continúe con la ejecución sin quedar bloqueado. Esta opción activa, que es el valor predeterminado en Postgres 18 Beta 1, mejora la paralelización y permite aprovechar mejor los recursos del sistema. Finalmente, el beneficio más impactante proviene del io_uring, una innovación introducida en versiones recientes del kernel Linux que utiliza un anillo compartido entre el espacio de usuario y el kernel.
Esta arquitectura minimiza la sobrecarga de llamadas al sistema (syscalls), disminuye la latencia y elimina la necesidad de procesos workers. Solo está disponible en sistemas Linux modernos y requiere configuraciones específicas del sistema de archivos para un funcionamiento óptimo. Los casos de uso más beneficiados por esta evolución se encuentran en entornos cloud donde la latencia de las lecturas puede ser un problema significativo. En pruebas realizadas con la infraestructura AWS, con dispositivos EBS con altas IOPS provisionadas, Postgres 18 demostró consistentemente duplicar en rendimiento la lectura comparado con Postgres 17 con I/O síncrono. La combinación de io_uring demostró incluso una mejora aún mayor, reduciendo en más de la mitad el tiempo de ejecución de consultas de lectura intensiva.
Otro aspecto importante para maximizar la eficiencia es la correcta configuración de parámetros como effective_io_concurrency, que en Postgres 18 se vuelve más relevante y rinde mejor junto con los métodos asíncronos. Este parámetro define cuántas solicitudes de lectura adelantadas pueden coexistir, ayudando al sistema a anticipar bloques de datos requeridos y aumentar la eficiencia del pipeline de lectura. Aunque los valores óptimos varían según el hardware y el patrón de datos, la comunidad recomienda aumentar su valor respecto a versiones previas para aprovechar los beneficios de la E/S asíncrona. Sin embargo, la adopción de E/S asíncrona viene acompañada de cambios y desafíos para la observabilidad y monitoreo. En sistemas antiguos, una consulta bloqueada por lectura podía identificarse fácilmente, ya que el proceso backend quedaba suspendido esperando la respuesta del disco.
Con el nuevo modelo, la espera puede ocurrir en procesos workers o directamente en el kernel, haciendo que las métricas tradicionales no reflejen el tiempo completo dedicado a la E/S. Para abordar esto, Postgres 18 introduce la vista pg_aios, una herramienta que permite monitorear las operaciones asíncronas activas y su estado, brindando información detallada sobre las lecturas en curso. Al mismo tiempo, las herramientas de monitoreo y análisis de rendimiento, como pganalyze, están evolucionando para adaptarse a estas nuevas realidades, asegurando que los administradores y desarrolladores puedan seguir obteniendo insights útiles sobre el comportamiento de sus bases de datos. Adoptar Postgres 18 significa también comprender que los tiempos reportados en EXPLAIN ANALYZE pueden mostrar una reducción aparente en los tiempos de E/S, ya que el backend no se bloquea directamente durante la lectura. Esta diferencia técnica obliga a replantear cómo se interpreta el esfuerzo real de lectura y a no confiar únicamente en los tiempos reportados para análisis de performance.
Aunque la versión inicial de Postgres 18 limita la E/S asíncrona a operaciones de lectura, el camino queda abierto para futuros avances, como la extensión a escrituras y el uso más intensivo de técnicas modernas de I/O como Direct I/O. Estos desarrollos anticipan una evolución continua para aumentar el rendimiento y la eficiencia en cargas de trabajo modernas, desde análisis de datos a aplicaciones web y empresariales. El impacto de esta transformación también se refleja en la planificación de infraestructuras. Empresas podrán reducir la necesidad de hardware más potente, optimizar costos en la nube y mejorar la escalabilidad de sus sistemas. Para cargas intensivas en lectura, la diferencia de rendimiento puede traducirse en una experiencia de usuario más rápida, tiempos de respuesta reducidos y un uso más eficiente del presupuesto tecnológico.
