Postgres 16 vs 17 vs 18: ganancias que importan

Las tres versiones no se distinguen por un único dato global de prestaciones. Cada uno corrige un punto específico de la arquitectura, con una audiencia diferente cada vez: tablas grandes para Postgres 17, almacenamiento de alta latencia para Postgres 18. La siguiente tabla resume los hechos verificables, todos fechados, antes de entrar en los detalles de cada proyecto.

Fuentes: notas de la versión oficial del proyecto PostgreSQL (postgresql.org), con referencias cruzadas con análisis publicados por Microsoft Tech Community y Crunchy Data después de cada lanzamiento importante. Consultado el 24 de agosto de 2026.

Antes de Postgres 17, VACUUM almacenaba la lista de tuplas muertas para limpiar en una matriz simple, con un tamaño de maintenance_work_mem. El problema no era la velocidad del cálculo, sino la estructura misma: esta tabla se estancó alrededor de 1 GB, sin importar cuánto se configurara más allá de eso. En una tabla con más de 178 millones de filas muertas, VACUUM tuvo que realizar múltiples pasadas, cada una releyendo los índices completos.

Postgres 17 reemplaza esta matriz con una estructura llamada TidStore, un árbol de base adaptable que comprime en gran medida el espacio necesario para almacenar identificadores de tupla. Las notas de la versión oficial del proyecto indican una reducción de la memoria utilizada por VACUUM de hasta 20 veces en algunos casos, sin el techo artificial asociado con la antigua estructura. Fuente: Notas de la versión oficial de PostgreSQL 17, postgresql.org, 26 de septiembre de 2024. Microsoft Tech Community y Crunchy Data publicaron un análisis técnico de este cambio poco después del lanzamiento. Ambos confirman el interés concreto por las tablas de varios cientos de millones de filas, con una alta tasa de eliminación o actualización.

Este proyecto beneficia principalmente a un escenario específico: una tabla grande con una alta tasa de eliminación o actualización. VACUUM anteriormente se ejecutó en varias pasadas debido a la falta de memoria disponible. En una mesa pequeña, o con una carga predominantemente de lectura, la ganancia sigue siendo marginal o incluso invisible.

El segundo proyecto de Postgres 17 toca un punto más discreto: el cálculo de instantáneas de transacciones. Cada consulta necesita saber qué otras transacciones están en progreso para hacer cumplir las reglas de visibilidad MVCC de Postgres. En una máquina con una gran cantidad de núcleos y conexiones activas, este cálculo generó competencia en una estructura interna compartida. Este es un cuello de botella que ha sido documentado durante mucho tiempo por los contribuyentes al proyecto.

Postgres 17 reduce este argumento. El efecto se mide principalmente en instancias de alta concurrencia, con muchas conexiones activas simultáneas en hardware de múltiples núcleos. Con una carga de concurrencia baja, la diferencia con Postgres 16 sigue siendo marginal: es un proyecto de escalabilidad, no una reducción de la latencia por solicitud aislada.

Esta ganancia no reemplaza a un agrupador de conexiones, simplemente reduce su costo interno. Si la cantidad de conexiones activas ya es su cuello de botella, la versión principal pasa a un segundo plano. Nuestra guía de ajuste de max_connections y nuestra comparación del modo de transacción PgBouncer exploran este tema con más detalle.

Postgres 18, lanzado a finales de septiembre de 2025, aborda un problema más estructural. Hasta entonces, cada lectura de disco de Postgres bloqueaba el proceso que la solicitaba. El nuevo subsistema de entrada y salida asíncrona (AIO) permite que un proceso inicie múltiples lecturas en paralelo y continúe trabajando mientras se completan, en lugar de esperar cada una de forma secuencial.

El parámetro io_method controla este comportamiento: worker (procesos dedicados a E/S, predeterminado) o io_uring en Linux, cuando Postgres se compiló con este soporte. Los escaneos secuenciales, los escaneos de mapas de bits y VACUUM son los primeros beneficiarios, particularmente en el almacenamiento de alta latencia: discos de red, volúmenes en la nube, en lugar de NVMe local.

PlanetScale, que ofrece una oferta de Postgres administrada, ha publicado sus propias comparaciones de Postgres 17 frente a 18 centradas en este cambio de E/S. Estas son sus mediciones sobre su propia infraestructura, no cifras que reproducimos aquí de forma independiente. Tómelo como una señal de que vale la pena probar el tema con su carga real, no como un porcentaje universal.

La AIO generalizada de Postgres 18 continúa un proyecto iniciado en Postgres 17, no un cambio aislado. La versión 17 ya había introducido la interfaz de E/S de transmisión, pero limitada a ANALIZAR y escaneos secuenciales. Postgres 18 extiende esta misma lógica a un alcance más amplio de operaciones, incluidos VACUUM y escaneos de montón de mapas de bits. Por lo tanto, las dos versiones se leen como una progresión, no como dos apuestas separadas sobre E/S.

Vale la pena monitorear otros tres cambios de Postgres 18, incluso si no abordan directamente el rendimiento bruto.

El omitir escaneo en un índice de árbol B de varias columnas permite a Postgres usar un índice compuesto incluso cuando la consulta no filtra en su columna principal. Antes de Postgres 18, este escenario a menudo requería un escaneo completo de la tabla o la creación de un índice dedicado adicional.

Las columnas virtuales generadas por (GENERATED ALWAYS AS (...) VIRTUAL) se convierten en el comportamiento predeterminado cuando no se especifica STORED. Una columna virtual se calcula durante la lectura en lugar de escribirse en el disco, lo que reduce la cantidad escrita cada vez que se inserta o actualiza la fila de origen.

Postgres 18 finalmente agrega soporte para OAuth 2.0 en el lado de la autenticación (RFC 8628, flujo de dispositivos), junto con mecanismos existentes como SCRAM, certificados o LDAP. Un punto relevante para cualquier organización que ya centralice sus identidades a través de un proveedor externo de OAuth/OIDC.

En Aurabase, la base de datos de inquilinos actualmente se ejecuta en Postgres 16.15, no en 17. Esto se puede verificar directamente en el repositorio: la imagen CNPG de referencia (docker/Postgres.CNPG.Dockerfile) comienza desde ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, fijada por resumen, la misma versión principal que el nivel compartido (docker/Postgres.Dockerfile). Verificado el 24 de agosto de 2026.

El código también documenta el motivo. Un comentario de corrección en k8s_tenant.rs explica que una alternativa anterior apuntaba erróneamente a postgresql:17.2. La razón dada en ese momento, la imagen estándar no incluiría pgvector, resultó ser falsa tras la verificación. Ambas imágenes tienen pgvector: 0.8.0 en 17.2, 0.8.5 en 16-standard-bookworm medido en el grupo de flota.

El riesgo real, documentado en el comentario mismo, está en otra parte: CloudNativePG prohíbe cualquier degradación importante de la versión una vez que se ha creado un clúster. Una flota aprovisionada por error en Postgres 17 sería irreversible, mientras que todo lo que se validó de extremo a extremo en Aurabase estaba en Postgres 16.

// Se conserva la versión principal si TENANT_POSTGRES_IMAGE no está definida
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Este no es un juicio sobre Postgres 17 como tal. Es una política de prudencia operativa: no cambiar una flota de producción a una versión principal hasta que se haya realizado la validación de un extremo a otro. El mismo razonamiento se aplica a cualquier equipo que administre Postgres a través de CloudNativePG o un operador de Kubernetes equivalente. La cuestión no es sólo la ganancia de rendimiento esperada, sino también el camino de regreso si algo sale mal.

¿Debería migrar a Postgres 17 o 18 ahora?

Tres criterios permiten decidir sin esperar a una cifra universal. Primero, el tamaño y la tasa de mutación de sus tablas más grandes: si VACUUM ya se está ejecutando en varias pasadas, el sitio de trabajo de memoria de Postgres 17 se aplica directamente a su caso. Luego, su almacenamiento: en SSD local de baja latencia, la E/S asíncrona de Postgres 18 proporciona menos que en un volumen de red. Finalmente, el camino de regreso: en un operador que prohíbe una degradación importante, probar primero en un entorno desechable no es una precaución opcional.

En concreto, la misma regla se aplica a cualquier flota gestionada por un operador de Kubernetes. Primero aprovisione un clúster de prueba en la versión de destino y luego reproduzca una carga representativa de su producción en él. Toque el clúster real solo una vez que esta prueba haya sido validada de un extremo a otro, no solo leyendo las notas de la versión. Si su decisión también se refiere a la elección entre base dedicada y base compartida para absorber este tipo de cambio, nuestro artículo base dedicada versus base compartida explora este ángulo.

La elección entre Postgres 16, 17 y 18 no se trata sólo de qué versión es la "más rápida". Postgres 17 soluciona un problema estructural real de VACUUM en tablas grandes y reduce la contención en alta concurrencia. Postgres 18 va más allá con E/S asincrónicas, un cambio arquitectónico que requiere pruebas en su carga y almacenamiento reales antes de generalizarse.

El criterio que más a menudo se olvida no es el rendimiento, sino la reversibilidad. En un operador como CloudNativePG, una actualización de versión importante no se deshace después del hecho. Antes de cambiar una flota de producción, la verdadera pregunta no es sólo la ganancia esperada, sino también el camino de retorno si la prueba falla. Si se está preparando para esta actualización de versión, nuestra lista de verificación de ajuste de Postgres en producción detalla las configuraciones que se deben revalidar después de un cambio importante de versión.