Autovacuum de Postgres, desmitificado — el tuning que previene el pánico de wraparound a las 3 am

El wraparound de transaction ID encabeza mi lista de modos de fallo de Postgres que personalmente me han costado sueño. La mañana es siempre la misma: la Postgres de un cliente se ha puesto read-only a las 2 am, cada escritura rechazada con «database is not accepting commands to avoid wraparound data loss», y la única salida es un VACUUM FREEZE contra una tabla de 300 GB que va a tardar seis horas.

El autovacuum existe desde 2005. Los valores por defecto están calibrados para «BBDD pequeña, servidor pequeño» y están mal en cualquier base significativamente grande, de forma predecible.

Tuning por tabla para tablas grandes y con churn

ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_freeze_max_age = 100000000,
  autovacuum_vacuum_cost_limit = 2000
);

Cualquier tabla por encima de 10 GB o 10 M de filas recibe tuning por tabla. Los defaults de 20 % de scale factor y 200 M de edad XID hacen los autovacuums demasiado raros y demasiado grandes en tablas grandes.

El artículo completo cubre:

• Qué hace realmente el autovacuum (limpieza de dead tuples vs congelación XID)
• Las tres métricas que vigilar (dead_ratio, last_autovacuum, xid_age)
• Por qué el autovacuum_vacuum_cost_limit = 200 por defecto es ridículamente bajo en SSD
• Congelación proactiva para prevenir autovacuums anti-wraparound en horario laboral
• Bloat de índices y REINDEX CONCURRENTLY programado
• pg_repack para tablas que deben devolver espacio en disco al SO

Entregamos este baseline en cada base Postgres gestionada.