Cuando un dashboard tarda en cargar, la primera reacción suele ser optimizar el reporte: menos visuales, menos medidas, menos filtros. Pero muchas veces el cuello de botella real está un paso antes, en la consulta SQL que trae los datos. Estos son los ajustes que más impacto tienen en la práctica.
1. Evita SELECT * en el origen de datos
Traer todas las columnas de una tabla cuando el reporte solo usa cinco desperdicia ancho de banda, memoria y tiempo de transferencia. Declarar explícitamente las columnas necesarias reduce el volumen de datos movidos en cada actualización.
2. Agrega índices en las columnas que usas para filtrar y unir
Las columnas usadas en cláusulas WHERE, JOIN y GROUP BY son las candidatas naturales para un índice. Sin un índice adecuado, el motor de base de datos hace un escaneo completo de la tabla en cada consulta, algo especialmente costoso en tablas de hechos con millones de filas.
Ejemplo típico en un modelo de ventas
- Índice sobre la columna de fecha si el reporte siempre filtra por rango de fechas.
- Índice sobre las llaves foráneas usadas para unir la tabla de hechos con las dimensiones.
3. Preagregar en el origen en vez de agregar en el reporte
Si el dashboard solo necesita totales por mes y por región, no tiene sentido traer el detalle transaccional completo y dejar que la capa de visualización agregue millones de filas en cada interacción. Crear una vista o tabla de agregación en la base de datos (o un paso de agregación en Power Query) mueve ese trabajo a un lugar donde se puede indexar y cachear.
4. Filtra lo antes posible en la consulta, no después
Aplicar filtros de fecha, estatus o región directamente en el WHERE de la consulta —en vez de traer todo y filtrar después en la herramienta de BI— reduce el volumen de datos que viaja por la red y que la herramienta tiene que procesar en memoria.
5. Revisa el plan de ejecución antes de asumir que "la base de datos es lenta"
Antes de agregar más índices o cambiar de motor, vale la pena revisar el plan de ejecución (EXPLAIN / EXPLAIN ANALYZE en PostgreSQL, el plan de ejecución estimado en SQL Server) para confirmar dónde se está yendo realmente el tiempo. Muchas veces el problema no es la consulta en sí, sino una función aplicada sobre la columna filtrada que invalida el uso del índice.
La regla general: cada fila y cada columna que no llega a la consulta es tiempo de carga que no tienes que optimizar después en el dashboard.