Optimización de consultas e índices en PostgreSQL
Optimizamos las consultas e índices de tu base PostgreSQL para que las pantallas, los reportes y las APIs de tu aplicación respondan rápido. Medimos qué consultas consumen más tiempo, leemos sus planes de ejecución, creamos o ajustamos índices y reescribimos el SQL que hace falta, con mediciones antes y después de cada cambio.
Te respondemos con una propuesta concreta. Sin compromiso.
Cómo encontramos las consultas lentas
El primer paso no es crear índices sino medir. Activamos pg_stat_statements, una extensión que registra cuántas veces se ejecuta cada consulta y cuánto tiempo consume en total. Ordenamos por tiempo acumulado y no solo por la consulta más lenta: muchas veces el mayor problema es una consulta de duración media que se ejecuta miles de veces por hora. Sumamos el registro de consultas que superan cierto tiempo y, cuando hace falta, el registro automático de sus planes. Es parte de nuestro servicio de PostgreSQL.
Leer el plan de ejecución
El plan de ejecución es la estrategia que PostgreSQL elige para resolver una consulta: qué tablas lee, en qué orden, con qué índices y cómo combina los resultados. Lo obtenemos con EXPLAIN ANALYZE, que ejecuta la consulta y muestra cuánto tardó cada paso. Ahí aparecen las señales típicas: lecturas completas de tablas grandes, estimaciones de filas muy lejanas de la realidad u ordenamientos que no entran en memoria y van a disco.
Innovación en emprendimientos
¿Lo pensamos para tu proyecto?
Tipos de índices que usamos
| Tipo de índice | Para qué sirve |
|---|---|
| B-tree | Búsquedas por igualdad, rangos y ordenamientos; es el más común |
| Compuesto | Filtros por varias columnas, con el orden de columnas pensado para la consulta |
| Parcial | Indexar solo una parte de la tabla, como los pedidos pendientes |
| De cobertura | Responder la consulta solo con el índice, sin leer la tabla |
| GIN | Datos JSONB, arreglos y búsqueda de texto completo |
| GiST | Datos geográficos y rangos de fechas |
| BRIN | Tablas enormes ordenadas por fecha, como registros o eventos |
| Por expresión | Búsquedas sobre un valor calculado, como un email en minúsculas |
Más allá de los índices
Un índice no arregla todo. Otras mejoras que aplicamos con frecuencia:
- Reescribir consultas que impiden usar índices, por ejemplo al aplicar funciones sobre columnas filtradas.
- Eliminar consultas repetidas que un ORM ejecuta dentro de un bucle.
- Paginar por cursor en lugar de saltear filas.
- Actualizar y ampliar estadísticas, para que el planificador estime mejor.
- Vistas materializadas para reportes pesados que no necesitan datos al segundo.
- Ajustar la memoria de trabajo cuando los ordenamientos van a disco.
Cómo trabajamos
- Medimos la línea de base con las consultas que más tiempo consumen.
- Analizamos los planes y proponemos cambios priorizados por impacto.
- Probamos cada cambio en una copia con datos reales.
- Aplicamos en producción sin bloquear tablas, creando los índices de forma concurrente.
- Medimos de nuevo y comparamos.
Qué recibís
- Un informe con las consultas optimizadas y sus tiempos antes y después.
- Las migraciones con los índices nuevos y los eliminados.
- Cambios propuestos o aplicados en el código de la aplicación.
- Recomendaciones para que tu equipo escriba consultas eficientes.
Si tu aplicación está hecha en Laravel, combinamos este trabajo con la optimización en Laravel, que suma caché y escalabilidad. Para bases MySQL, mirá nuestra optimización de consultas MySQL.
Preguntas frecuentes
¿Tenés otra duda? Escribinos por WhatsApp.
¿Por qué una consulta que antes era rápida ahora es lenta?
Las causas más comunes son que la tabla creció y el índice que había ya no alcanza, que las estadísticas que usa PostgreSQL para planificar quedaron desactualizadas, o que la tabla acumuló filas muertas por falta de mantenimiento. También puede ser que alguien cambió la consulta en el código. El plan de ejecución muestra cuál de estas causas aplica.
¿Tener muchos índices es un problema?
Sí, puede serlo. Cada índice acelera ciertas lecturas, pero ocupa espacio y hace más lenta cada inserción y modificación, porque hay que actualizarlo. Es común encontrar índices duplicados o que ninguna consulta usa. Como parte de la optimización revisamos las estadísticas de uso y eliminamos los que solo suman costo.
¿Crear un índice bloquea la tabla?
Con el método común, la tabla no acepta escrituras mientras se construye el índice, lo que en una tabla grande puede significar minutos sin poder guardar datos. Por eso en producción usamos la opción concurrente de PostgreSQL, que construye el índice sin bloquear las escrituras, a cambio de tardar algo más.
¿Qué es la paginación por cursor y por qué es más rápida?
La paginación tradicional le pide a la base que saltee cierta cantidad de filas, y cuanto más avanzás, más filas tiene que leer y descartar. La paginación por cursor pide las filas siguientes a la última que se mostró, usando un índice, así que la página mil es tan rápida como la primera. Es ideal para listados largos y APIs.
¿Pueden optimizar consultas generadas por un ORM?
Sí. Un ORM como Eloquent genera SQL que se puede analizar igual que cualquier otro. Los problemas típicos son las consultas repetidas dentro de un bucle, que se resuelven con carga anticipada de relaciones, y las consultas que traen columnas o filas de más. Corregimos el código de la aplicación, no solo la base.
Pedí tu presupuesto
Optimización de consultas e índices en PostgreSQL, pensado para tu emprendimiento. Contanos qué necesitás y te respondemos con una propuesta.
- Tres pasos, menos de dos minutos.
- Propuesta concreta, sin compromiso.
- Si preferís, lo hablamos por WhatsApp.
- Qué necesitás
- Tu proyecto
- Tus datos
También te puede servir
- Optimización de consultas MySQL lentas en sitios, tiendas y sistemas MySQL
- Optimización de rendimiento en Supabase: consultas, índices y recursos Supabase
- Optimización de sitios en Laravel: consultas, caché y escalabilidad Laravel
- Diseño de bases de datos PostgreSQL pensadas para crecer PostgreSQL
- Instalación y configuración de servidores PostgreSQL para producción PostgreSQL
- Actualización de versión de PostgreSQL sin perder datos PostgreSQL