Una base de datos PostgreSQL lenta bajo presión de producción invita a adivinar, y adivinar es como salen mal los rescues. Añadir un índice, subir un parámetro de memoria o reiniciar un servidor puede esconder el cuello de botella real e introducir nuevo riesgo. El trabajo que de verdad aguanta parte de evidencia y cambia una cosa a la vez.
Cuándo aparece el problema
La llamada suele llegar cuando algo visible se rompe: las páginas dan timeout en pico, los background jobs se acumulan, un reporte nocturno ya no termina, o el número de conexiones sube hasta que la aplicación no puede abrir nuevas sesiones. A menudo nada cambió en la query, solo el volumen de datos. A veces un deploy añadió una query que parece inofensiva y corre un sequential scan sobre una tabla que ha crecido en silencio a decenas de millones de filas. El primer trabajo no es arreglar nada. Es describir el incidente con precisión.
Modos de fallo comunes
Ajustar parámetros antes de leer queries. Subir work_mem o shared_buffers se siente productivo, pero si el plan de una query está mal, la perilla global solo reparte el coste. Evidencia primero, parámetros después.
Indexar por intuición. Los índices que no coinciden con ninguna query real añaden overhead de escritura y bloat sin ayudar a las lecturas. Los índices sin uso son un coste, no un seguro.
Ignorar locks y transacciones largas. Una sola transacción de larga duración puede bloquear autovacuum, retener locks y frenar todo lo que va detrás. El síntoma de lentitud es a menudo un problema de locks disfrazado de performance.
Dejar que bloat y autovacuum se desvíen. Tablas e índices acumulan bloat cuando autovacuum no da abasto, y el bloat degrada poco a poco cada query contra ellos. Es invisible hasta que lo mides.
Cambiar producción a ciegas. Un arreglo que funciona sobre un dataset pequeño puede comportarse muy distinto contra datos de tamaño producción. Sin una prueba parecida a producción, “funcionó en local” no es tranquilizador.
Cómo investigar
Empieza por la forma del incidente, luego acota con evidencia.
Describe el síntoma con precisión
Páginas lentas, jobs retrasados, esperas por locks, CPU alta, presión de IO, agotamiento de conexiones o latencia creciente apuntan cada uno a un camino distinto. Nombrar el síntoma acota la búsqueda antes de tocar nada.
Lee las queries
Encuentra las sentencias lentas, mira sus planes de ejecución, compara las estimaciones de filas con la realidad y revisa índices ausentes, índices sin uso y full scans repetidos. Un puñado de planes suele contar una historia más clara que cualquier consejo genérico de tuning.
Revisa la capa operativa
Inspecciona locks, transacciones largas, salud de autovacuum, bloat de tablas e índices, comportamiento reciente de migraciones, connection pooling y presión de background jobs. Una base de datos lenta es con frecuencia un problema de sistema, no solo de SQL.
Checklist operativa
- El incidente tiene un síntoma nombrado, no solo “la base de datos está lenta”.
- Las queries lentas se identifican desde evidencia, con planes capturados.
- Las estimaciones de filas se comparan con filas reales para detectar estadísticas obsoletas.
- Locks y transacciones de larga duración se han descartado o confirmado.
- La salud de autovacuum y el bloat se miden, no se asumen.
- Connection pooling y concurrencia de jobs están contemplados.
- Cada cambio propuesto tiene un rollback y una forma de verificarlo.
Un camino seguro
Mide, aísla un cuello de botella, cambia la cosa útil más pequeña, verifica en condiciones parecidas a producción y mantén claras las opciones de rollback. Resiste el impulso de aplicar cinco cambios a la vez; si algo mejora, no sabrás cuál cambio lo hizo, y si algo se rompe, no sabrás cuál deshacer. Un cambio, una medición, repetir.
Este trabajo de base de datos suele llegar como parte de la modernización y rescue de infraestructura. Conecta con nuestros servicios más amplios y con el pensamiento de modernización en la checklist de modernización Rails. Si una base de datos de producción está bajo presión, cuéntanos qué se rompe y empezaremos desde la evidencia.
Este artículo es guía general de ingeniería, no consejo para un sistema específico. Un rescue real siempre debería empezar con mediciones de tu propio entorno de producción.