Hinchazón (bloat) en Postgres y ajuste de autovacuum para un rendimiento más rápido

Qué es el bloat en Postgres y por qué importa autovacuum

El bloat es el espacio extra y desperdiciado dentro de las tablas e índices de Postgres que se acumula con el tiempo. Suele aparecer tras una dieta constante de UPDATEs y DELETEs. Postgres no sobrescribe filas en su lugar: escribe una nueva versión de la fila y deja la antigua hasta que se limpia.

Ese espacio desperdiciado perjudica el rendimiento de formas previsibles. Las consultas tienen que leer más páginas desde disco y memoria para encontrar la misma cantidad de datos reales. Los índices crecen, por lo que las búsquedas y los joins requieren más trabajo. Las escrituras también pueden ralentizarse porque Postgres debe mantener índices más grandes y tocar más páginas. Los backups y restores tardan más porque hay más que copiar.

Autovacuum es el trabajador en segundo plano que mantiene esto bajo control. Hace principalmente dos tareas:

• Limpia versiones de filas muertas para que su espacio pueda reutilizarse (VACUUM)
• Actualiza las estadísticas del planificador para que Postgres elija buenos planes de consulta (ANALYZE)

Un detalle importante: autovacuum normalmente no encoge el archivo físico en disco. Hace que el espacio sea reutilizable dentro de la tabla, pero el uso de disco puede no bajar. Para devolver espacio al SO normalmente necesitas mantenimiento más pesado (como VACUUM FULL o reconstruir la tabla), y esas opciones tienen costes reales.

Un ejemplo sencillo: un panel de administración generado por IA que “actualiza” registros de usuario en cada carga de página puede crear un flujo constante de filas muertas. Autovacuum puede aguantar un tiempo. Luego llega un pico de tráfico, se queda atrasado y de repente las consultas comunes se sienten lentas aunque el tamaño del conjunto de datos no haya cambiado mucho.

Ajustar autovacuum no es un interruptor único. La configuración correcta depende de la tasa de escrituras, el tamaño de la tabla y cuánto toleras el trabajo en segundo plano. El enfoque más seguro es iterativo: medir, hacer cambios pequeños, observar el impacto y ajustar.

Señales comunes de que tu base de datos sufre bloat

El bloat suele aparecer como “nada cambió, pero todo va más lento”. Los datos del negocio pueden parecer estables, pero Postgres tiene que leer y escanear más páginas para responder las mismas consultas. Ese trabajo extra se traduce en más IO, más CPU y más esperas.

Señales que suelen indicar bloat:

• Consultas que iban bien la semana pasada ahora tardan, especialmente las que antes hacían index scans rápidos.
• El uso de disco sigue subiendo aunque los datos reales no crezcan al mismo ritmo.
• Mayor latencia de lectura y más fallos de caché (más lecturas desde disco en lugar de memoria).
• Autovacuum corre a menudo, pero no ves la recuperación habitual después.
• Backups y restores tardan más, y aparece lag de replicación en periodos de mucha carga.

Una pista sutil es cuando el plan de consulta sigue siendo “correcto” (sigue usando el índice esperado), pero el tiempo empeora mucho. Eso puede pasar cuando el índice está hinchado y es más grande de lo necesario, así Postgres necesita más lecturas de páginas para recorrerlo.

Otro patrón común: los escaneos de tabla se vuelven más lentos aunque el conteo de filas parezca similar. Las actualizaciones y eliminaciones dejan tuplas muertas, y cuando la limpieza se queda atrás la tabla crece en páginas. Postgres entonces tiene más páginas que buscar y más comprobaciones de visibilidad que hacer.

Un ejemplo práctico: una pequeña SaaS añade un update last_seen en cada petición. Las lecturas empiezan a agotar tiempo durante las horas punta, el uso de disco sube y autovacuum parece ocupado todo el día. La causa raíz no es una consulta mala; es la base de datos haciendo trabajo extra porque se han acumulado filas muertas e índices sobredimensionados.

Si ves dos o más de estas señales al mismo tiempo, mide el bloat antes de cambiar configuraciones. Los ajustes de autovacuum ayudan más cuando puedes confirmar qué tablas e índices están creciendo realmente.

Lista rápida: confirma bloat antes de tocar

Antes de cambiar nada, confirma que realmente estás ante bloat y no ante un plan de consulta lento, índices malos o una transacción que bloquea la limpieza. Ajustar funciona mejor cuando puedes señalar unas pocas tablas e índices concretos.

Empieza por obtener números rápidos y sencillos para comparar semana a semana. Concéntrate en:

• Las tablas más grandes y si realmente reciben muchas escrituras (las tablas frías rara vez explican bloat).
• Historial de autovacuum por tabla: cuándo corrió por última vez, con qué frecuencia y si tarda más con el tiempo.
• Altos conteos de tuplas muertas, especialmente en tablas con muchas actualizaciones.
• Índices grandes sobre columnas con mucho churn (los índices pueden hincharse aunque la tabla parezca bien).
• Transacciones de larga duración, ya que pueden impedir que VACUUM elimine tuplas muertas.

Si quieres una pasada rápida, estas consultas suelen dar suficiente señal para decidir qué investigar:

-- Biggest tables
SELECT relname, pg_total_relation_size(relid) AS bytes
FROM pg_catalog.pg_statio_user_tables
ORDER BY bytes DESC
LIMIT 5;

-- Dead tuples and last vacuum/autovacuum
SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;

-- Biggest indexes
SELECT indexrelname, pg_relation_size(indexrelid) AS bytes
FROM pg_stat_user_indexes
ORDER BY bytes DESC
LIMIT 10;

-- Long-running transactions (can block cleanup)
SELECT pid, now() - xact_start AS xact_age, state
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_age DESC
LIMIT 10;

Una forma práctica de leer los resultados: si una tabla tipo events es enorme, tiene un conteo de tuplas muertas en aumento y autovacuum corre pero nunca se pone al día, esa tabla es candidata a tuning. Si las tuplas muertas son altas en muchas tablas y además ves una transacción que dura horas, arregla la transacción larga primero. Autovacuum no puede con una transacción que nunca termina.

Cómo medir el bloat de tablas e índices (métodos prácticos)

Empieza con lo que Postgres ya rastrea. El bloat suele correlacionarse con muchas tuplas muertas y mucho churn (updates y deletes) en las mismas tablas.

1) Usa estadísticas integradas para encontrar tuplas muertas y churn

Estas vistas son una pasada rápida y de bajo riesgo. Busca tablas donde n_dead_tup sea alto y donde n_tup_upd y n_tup_del sigan subiendo.

-- Tables with lots of dead tuples
SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  last_autovacuum,
  last_vacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

-- Churn (writes) that tends to create bloat
SELECT
  schemaname,
  relname,
  n_tup_ins,
  n_tup_upd,
  n_tup_del,
  n_tup_hot_upd
FROM pg_stat_user_tables
ORDER BY (n_tup_upd + n_tup_del) DESC
LIMIT 20;

Una regla simple: si las tuplas muertas son una gran parte de las tuplas vivas y autovacuum no corre a menudo (o tarda mucho), probablemente tengas bloat y deberías investigar los ajustes de autovacuum y los bloqueos.

2) Estima bloat sin matemáticas pesadas

Manténlo práctico. Compara cuánto ocupa la relación en disco versus cuántas filas vivas tiene. Si una tabla es enorme pero las filas vivas no lo son, la diferencia suele ser bloat o filas muy anchas. Puedes confirmar después con herramientas más profundas.

También comprueba si la tabla creció rápido y nunca se redujo. Postgres no devuelve espacio al SO automáticamente tras deletes y updates normales, por eso bloat y autovacuum se discuten juntos.

3) Revisa tamaño de índices y su utilidad

Los índices también pueden hincharse, y los índices sin uso son un coste escondido. Compara tamaño con la frecuencia con que Postgres recorre el índice.

SELECT
  s.schemaname,
  s.relname AS table_name,
  s.indexrelname AS index_name,
  pg_relation_size(s.indexrelid) AS index_bytes,
  s.idx_scan
FROM pg_stat_user_indexes s
ORDER BY pg_relation_size(s.indexrelid) DESC;

Si un índice es grande y idx_scan está cerca de cero bajo tráfico real, es candidato a eliminar o rediseñar. Confirma que no es necesario para constraints, unicidad o una consulta rara pero crítica antes de tocarlo.

4) Cuándo usar herramientas de inspección más profundas

Si necesitas números reales de bloat, usa pgstattuple (o pgstattuple_approx para tablas grandes). Puede reportar espacio muerto y densidad de tuplas, pero es más costosa que las vistas de estadísticas, así que ejecútala en periodos de baja carga.

5) Anota una línea base

Antes de cambiar nada, guarda una instantánea: tablas principales por n_dead_tup, índices principales por tamaño y algunos tiempos de consulta clave. Después del tuning y mantenimiento sabrás qué mejoró realmente.

Por qué autovacuum se queda atrás en aplicaciones reales

Autovacuum es el equipo de limpieza en segundo plano de Postgres. Elimina las filas muertas que dejan los updates y deletes y mantiene estadísticas frescas para que los planes sigan siendo razonables. Decide cuándo correr usando umbrales que son en parte fijos y en parte basados en el tamaño de la tabla.

Para cada tabla, Postgres espera hasta que el número de filas cambiadas cruce un disparador como:

• un número base (autovacuum_vacuum_threshold)
• más un porcentaje de la tabla (autovacuum_vacuum_scale_factor)

Eso funciona bien para muchas tablas. Pero las tablas con muchas actualizaciones (sessions, events, job queues) pueden generar filas muertas más rápido de lo que esos disparadores disparan, especialmente si el scale factor es demasiado alto. La tabla crece, el disparador crece con ella y vacuum llega tarde.

Bloqueos reales que impiden la limpieza

La razón más común por la que vacuum no puede eliminar filas muertas es una transacción larga. Si alguna transacción queda abierta, Postgres debe conservar versiones antiguas de filas, aunque todos los demás hayan terminado. Esto puede suceder con sesiones idle-in-transaction (una pestaña abierta), un worker atascado o un job por lotes que agrupa demasiado trabajo en una sola transacción.

Aunque vacuum pueda ejecutarse, puede ser demasiado suave. Autovacuum tiene límites de coste (cuánto IO puede usar antes de dormir). En sistemas muy ocupados, esos límites suelen ser conservadores, por lo que vacuum progresa despacio mientras la app sigue generando más filas muertas.

Causas ocultas que empeoran la situación

Algunos patrones empujan regularmente a autovacuum a quedarse atrás: grandes actualizaciones/eliminaciones por lotes que tocan la mayoría de filas de una vez, tablas calientes con UPDATEs frecuentes (aunque sean pequeños), conexiones idle-in-transaction que mantienen snapshots, informes de larga duración que mantienen transacciones abiertas y picos de tráfico donde vacuum no logra ponerse al día entre oleadas.

Al investigar bloat, empieza por encontrar dos cosas: la tabla que más churn genera y la transacción más larga que nunca termina. Arregla eso primero y luego ajusta configuraciones.

Paso a paso: afina autovacuum de forma segura (empieza poco a poco)

La forma más segura de afinar autovacuum es cambiar una cosa, en una tabla, y observarla durante un día entero. La mayoría de los problemas de autovacuum vienen de unas pocas tablas con mucho churn (sessions, events, logs, tablas de colas), no de toda la base de datos.

Elige una tabla con muchas actualizaciones o eliminaciones que muestre lentitud. Un buen candidato suele tener un conteo de tuplas muertas que crece rápido y escrituras frecuentes durante tráfico normal.

Una secuencia pequeña y controlada que suele funcionar bien:

1. Escoge una tabla con mucho churn y registra una línea base: número de filas, tuplas muertas y frecuencia de autovacuum.
2. Reduce los scale factors y umbrales por tabla para que el mantenimiento corra antes (antes de que la tabla se haga enorme). Mantén el cambio moderado.
3. Si vacuum es muy lento, ajusta la capacidad con cuidado: aumenta un poco autovacuum_max_workers o sube autovacuum_vacuum_cost_limit para que los vacuums avancen sin aplastar la app.
4. Confirma que ANALYZE mantiene los planes precisos observando menos cambios inesperados de plan y tiempos de consulta más estables.
5. Supervisa durante un día completo de tráfico real y compara: tuplas muertas, frecuencia de vacuum, latencia de consultas y uso de CPU/IO.

Un ajuste práctico por tabla suele verse así:

ALTER TABLE public.events SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_threshold = 1000
);

Luego valida con las estadísticas que ya tienes:

SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_all_tables
WHERE schemaname = 'public'
ORDER BY n_dead_tup DESC
LIMIT 10;

Ejemplo: una app escribe 5 millones de filas de eventos al día y elimina las antiguas cada hora. Con la configuración por defecto, vacuum empieza tarde y las filas muertas se acumulan. Bajando los scale factors sólo para events, autovacuum corre más a menudo, el tiempo de consulta se mantiene más estable y evitas mantenimientos pesados y riesgosos en horas punta.

Si heredaste una app generada por IA donde los patrones de escritura son desordenados (bucles de reintento, inserts duplicados, tormentas de updates), vale la pena arreglar la causa raíz. Si no, acabarás afinando autovacuum para compensar un comportamiento de aplicación defectuoso.

Paso a paso: recuperar espacio y velocidad sin romper la disponibilidad

Empieza con las herramientas menos disruptivas. La mayoría de las veces puedes obtener ganancias notables sin bloquear escrituras ni detener la app.

1) Ejecuta un VACUUM normal (suele ser seguro y a menudo suficiente)

Un VACUUM estándar elimina versiones de filas muertas para que Postgres pueda reutilizar ese espacio dentro de la tabla. También actualiza información de visibilidad para que los index scans y sequential scans puedan mejorar. No encoge el archivo en disco, pero a menudo detiene la fuga y mejora la velocidad de consultas.

Si puedes, hazlo en lotes más pequeños (una tabla grande a la vez) en periodos de baja carga. Ejemplo:

VACUUM (ANALYZE) public.big_table;

2) Reconstruye índices hinchados (cuando las consultas siguen lentas)

Si VACUUM en la tabla ayudó poco, los índices pueden ser el principal problema. Los índices hinchados hacen que las lecturas sean más lentas y aumentan el IO aleatorio. En producción, prefiere una reconstrucción concurrente para que lecturas y escrituras sigan funcionando:

REINDEX INDEX CONCURRENTLY public.big_table_some_idx;

Espera que lleve tiempo y que use espacio temporal extra mientras se construye el índice nuevo.

3) Usa VACUUM FULL sólo si aceptas tiempo de inactividad

VACUUM FULL reescribe toda la tabla y puede devolver espacio al SO. Es disruptivo porque toma un lock exclusivo en la tabla. Eso significa que inserts, updates y a menudo lecturas quedarán bloqueadas.

Úsalo sólo cuando tengas una ventana de mantenimiento clara y el espacio en disco sea realmente urgente.

4) Opciones más seguras para tablas muy grandes

Si una tabla es gigantesca y necesitas espacio sin bloquear durante mucho tiempo, planifica una ventana de mantenimiento y usa enfoques como: reconstruir primero los índices más dañados con REINDEX CONCURRENTLY, considerar particionar o archivar datos antiguos y soltar particiones viejas, o usar una estrategia de reescritura (copiar a una tabla nueva y hacer swap) cuando puedas controlar el corte.

5) Verifica que realmente mejoraste

No confíes en sensaciones. Compara antes y después con comprobaciones sencillas:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;

También vuelve a comprobar tamaños y tiempos de consulta. Si el bloat vuelve rápido, la causa raíz suele ser comportamiento de la app (updates masivos, índices faltantes, transacciones largas).

Un calendario de mantenimiento para que el bloat no vuelva

Un buen plan de mantenimiento es aburrido a propósito. Hace que el bloat sea una tarea rutinaria en vez de una caída sorpresa. El objetivo no es una mejora única, sino un ritmo estable que coincida con cómo tu app escribe datos.

Empieza eligiendo ventanas de mantenimiento usando tráfico real. Observa tus 30 a 60 minutos más ocupados cada día y evítalos. Si no tienes gráficas, usa pistas sencillas: horarios de checkout, jobs diarios por lotes, envíos de marketing y picos en tickets de soporte.

Un ritmo semanal simple que funciona para muchos equipos:

• Revisa las 5 tablas e índices más grandes. Comprueba tuplas muertas y tiempos recientes de vacuum.
• Ejecuta VACUUM (ANALYZE) manual en las tablas más calientes si autovacuum va regularmente detrás.
• Busca transacciones largas que bloqueen vacuum.

Una vez al mes, añade una pasada más pesada cuando el tráfico sea mínimo. Autovacuum debe manejar el churn normal. El trabajo manual es para excepciones: tablas con picos, grandes borrados y cambios de esquema.

Para la lista mensual, mantenla corta y medible:

• Compara crecimiento de tablas e índices respecto al mes pasado.
• Comprueba si la duración del vacuum tiende a subir.
• Decide si alguna tabla necesita ajustes personalizados de autovacuum (umbrales, scale factors, límites de coste).
• Programa un REINDEX dirigido (o una reconstrucción controlada) sólo cuando puedas tolerar la carga extra.

Rastrea unas pocas métricas con el tiempo: tuplas muertas (n_dead_tup), tamaño de tabla vs total incluyendo toast, tamaños de índices y timestamps de vacuum/analyze. Cuando lances nuevas funcionalidades, planifica con antelación: cualquier tabla nueva con muchas escrituras debería empezar con ajustes sensatos de autovacuum y entrar en tu revisión semanal.

Errores comunes que empeoran bloat y rendimiento

La mayoría de los problemas de bloat se agravan porque la “solución” se aplica de forma demasiado amplia y rápida. Obtendrás mejores resultados si cambias una cosa, mides y luego cambias la siguiente.

1) Sobreajustar autovacuum y crear picos de IO

Subir mucho los ajustes de autovacuum en toda la base de datos puede disparar lecturas y escrituras en disco. Eso puede ralentizar consultas de usuario, aumentar latencia y aún así no solucionar el mayor bloat si el problema real son unas pocas tablas calientes.

Un enfoque más seguro es afinar por tabla para el puñado de tablas que generan más churn (sessions, event logs, colas) y luego observar el impacto.

2) Usar VACUUM FULL en una tabla ocupada sin plan

VACUUM FULL puede recuperar espacio, pero reescribe la tabla y normalmente bloquea el acceso mientras corre. En una tabla ocupada en producción, eso puede parecer una caída.

Si necesitas recuperar mucho espacio, planifica una ventana de mantenimiento, considera alternativas y confirma que tienes disco libre suficiente para la reescritura.

3) Ignorar transacciones largas y culpar a autovacuum

Autovacuum no puede eliminar tuplas muertas si una transacción larga mantiene snapshots antiguos. Verás tuplas muertas acumulándose aunque autovacuum corra constantemente.

Causas comunes: sesiones de administrador olvidadas, jobs en background que no hacen commit o código de app que abre una transacción y luego hace trabajo lento.

4) Cambiar sólo configuraciones globales en vez de arreglar hotspots

Las configuraciones globales de autovacuum son una herramienta tosca. El bloat suele concentrarse en tablas e índices específicos, que a menudo necesitan umbrales y costes propios.

Si ajustas globalmente, puedes desperdiciar recursos en tablas frías mientras la tabla problemática sigue creciendo.

5) Medir una vez, cambiar cinco cosas y perder la línea base

Si ajustas varios parámetros a la vez no sabrás qué ayudó. Mantén una línea base simple (tamaños de tabla, tuplas muertas, tiempos de vacuum/analyze, latencia de consultas) y cambia una variable a la vez.

Ejemplo: de consultas lentas a rendimiento estable en una semana

Una startup lanza un feed de actividad: likes, comentarios y marcas de “visto”. De la noche a la mañana, las escrituras pasan de unas docenas por segundo a varios miles. La app sigue funcionando, pero las páginas que antes cargaban en 200 ms ahora tardan 2 a 5 segundos.

En dos días, destacan dos cosas: los índices crecen rápido, el uso de disco sigue aumentando aunque las filas antiguas se “eliminen” y llegan alertas de poco espacio. La latencia de consultas también se vuelve irregular: bien unos minutos y de repente lenta.

Lo que encontramos

El hotspot es una tabla que cambia constantemente, por ejemplo activity_events. Tiene actualizaciones frecuentes (flags de estado) y deletes (limpieza por retención). Autovacuum corre, pero siempre llega tarde porque la tabla alcanza su umbral rápidamente y sigue cambiando mientras vacuum intenta ponerse al día. Las tuplas muertas se acumulan, los índices se hinchan y consultas simples terminan leyendo muchas más páginas de las necesarias.

Lo que cambiamos (sin mantenimientos arriesgados)

Lo arreglamos con pasos pequeños y dirigidos:

• Configuramos umbrales por tabla para que esa tabla de alto churn vacuumee antes y con más frecuencia.
• Incrementamos trabajo de autovacuum para esa tabla (límite de coste o workers) para que termine antes del siguiente pico.
• Ejecutamos un reindex dirigido en los índices peor hinchados durante una ventana de baja carga.
• Programamos una ventana semanal de mantenimiento para las pocas tablas que más churn generan.
• Ajustamos los jobs de retención para borrar en lotes más pequeños y así permitir que vacuum siga el ritmo.

Al final de la semana, el crecimiento del disco se aplanó y se mantuvo predecible. La latencia de consultas dejó de oscilar salvajemente y el feed de actividad volvió a ser estable.

Siguientes pasos: mantener la estabilidad y arreglar la causa raíz

Una vez que el bloat está bajo control, el objetivo cambia: evitar que vuelva. La forma más segura es hacer un cambio a la vez y observar qué pasa. Así no intercambias un problema por otro.

Empieza por el peor culpable (una tabla o una tabla de colas con muchas actualizaciones) y haz un cambio claro. Por ejemplo: bajar umbrales y scale factors para esa tabla, subir el límite de coste para que vacuum termine, reducir el churn en la app evitando reescrituras innecesarias o añadir alertas para tuplas muertas, retraso de vacuum y transacciones largas.

Después de cada cambio, sigue unos números durante una semana: crecimiento de la tabla, tuplas muertas, frecuencia de autovacuum y p95 de latencia para los endpoints que tocan esa tabla. Si no ves mejora, revierte y prueba la siguiente idea.

Escribe un pequeño runbook que tu equipo pueda repetir:

• Qué métrica dispara la acción (ejemplo: tuplas muertas sobre X% o retraso de vacuum sobre Y horas)
• Qué cambias primero (ajustes por tabla antes de globales)
• Cómo verificas el éxito (dos métricas y una comprobación visible para usuario)
• Qué evitar (VACUUM manual en hora pico, transacciones largas)
• Quién toma la decisión y cuándo escalar

Si tu app fue generada por IA, busca patrones que crean churn constante: escrituras muy frecuentes (actualizar filas en cada petición), índices faltantes en claves foráneas y manejo de sesiones que deja transacciones abiertas. Un ejemplo común es un prototipo que escribe last_seen en cada carga de página.

Cuando sigues afinando pero el rendimiento sigue degradándose, normalmente es un problema de comportamiento del producto, no del vacuum. Si tratas con una base de código generada por IA que ataca Postgres de formas extrañas (flujos de auth rotos, bucles de reintento, jobs que no paran), FixMyMess en fixmymess.ai puede ayudar a diagnosticar y reparar esas rutas de código para que la base de datos deje de pelear una batalla perdida.