EXPLAIN ANALYZE en PostgreSQL: encontrar consultas lentas paso a paso
Publicado el 2026-10-26 por frfrand
Plan de ejecución e índices de PostgreSQL para optimizar APIs
Una lista de reservas tarda tres segundos y alguien propone duplicar el VPS. Antes de pagar más CPU, mirá cómo PostgreSQL ejecuta esa consulta. EXPLAIN ANALYZE te muestra el plan real, tiempos y filas procesadas.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace EXPLAIN ANALYZE en PostgreSQL
EXPLAIN estima un plan sin ejecutar la consulta; con ANALYZE sí la ejecuta y registra métricas reales. En SELECT suele ser apropiado para analizar, pero con operaciones que modifican datos puede producir cambios: nunca lo ejecutes alegremente en consultas de escritura de producción.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo concreto
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, fecha, estado
FROM reservas
WHERE cliente_id = 42
ORDER BY fecha DESC
LIMIT 20;
-- Comparar estimaciones y ejecución real
EXPLAIN SELECT * FROM reservas WHERE cliente_id = 42;Los nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Reproducí la lentitud con datos similares a producción y una SELECT representativa.
- Observá duración total, filas estimadas y filas reales.
- Identificá escaneos secuenciales grandes, ordenaciones costosas y accesos repetidos.
- Evaluá un índice compatible con filtros y orden, pero comprobá el efecto sobre escrituras.
- Volvé a medir la consulta y el p95 de la API, no sólo el coste estimado del plan.
Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
Una plataforma de reservas busca los últimos pedidos de cada cliente. Un índice compuesto sobre (cliente_id, fecha DESC) puede mejorar la consulta si coincide con los patrones de acceso y distribución de datos.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
Crear índices por cada columna no es gratis; ocupan espacio y penalizan algunas escrituras. ANALYZE ejecuta consultas: no uses ejemplos de DELETE/UPDATE en producción sin transacción y controles explícitos.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guardá una copia verificable o migración reversible y comprobá que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
En PostgreSQL alojado en ArduMaker podés revisar consultas lentas y recursos del VPS. Si el cuello está en un plan SQL ineficiente, subir CPU no necesariamente ayuda.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder sólo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabés restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si podés responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando sólo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.