Cuando Power BI está lento, no conviene empezar “optimizando gráficos” al azar. El diagnóstico debe recorrer toda la cadena: fuente de datos → consultas → transformaciones → modelo semántico → DAX → actualización → infraestructura/capacidad → visualizaciones. Medir primero permite encontrar el cuello de botella real.
Power BI es el último eslabón de una cadena
El usuario ve una página con gráficos. Detrás puede existir una base SQL Server, un ERP, APIs, archivos, Power Query, un modelo semántico, medidas DAX, un gateway y una capacidad de cómputo. Si cualquiera de esas capas trabaja de manera ineficiente, la experiencia final se degrada.
Por eso, “Power BI está lento” no es todavía un diagnóstico. Es apenas una descripción del síntoma.
1. La fuente ya responde lentamente
Antes de revisar DAX, conviene preguntar cuánto tarda la fuente en entregar la información. Una consulta SQL ineficiente, índices inadecuados, bloqueos, estadísticas desactualizadas o falta de recursos pueden hacer que todo lo que viene después espere.
En escenarios DirectQuery, este punto es especialmente sensible porque la experiencia del usuario depende más directamente del tiempo de respuesta de la fuente. Incluso en modo Import, una consulta lenta puede convertir cada actualización en un proceso innecesariamente extenso.
2. Se está trayendo más información de la necesaria
Columnas que nadie usa, históricos completos cuando solo se analizan algunos años, tablas auxiliares sin propósito o datos con una granularidad mucho mayor a la requerida aumentan el tamaño del modelo y el trabajo de actualización.
Una regla simple ayuda: cada columna y cada fila deberían justificar su presencia en el modelo. Reducir datos no significa perder valor; significa evitar que el modelo cargue información que no participa en ninguna decisión.
3. Power Query está haciendo trabajo que podría resolverse mejor
Power Query es una herramienta muy potente, pero la ubicación de cada transformación importa. Cuando es posible, el query folding permite que parte del procesamiento sea ejecutado por la fuente en lugar de realizarse completamente en el motor de Power Query.
Microsoft recomienda prestar especial atención al plegado de consultas, sobre todo en DirectQuery y Dual, y minimizar el trabajo local cuando las transformaciones sobre grandes volúmenes podrían delegarse al origen.
Si la actualización se vuelve lenta, conviene revisar qué pasos rompen el query folding, qué transformaciones pueden llevarse a SQL, a un proceso ETL/ELT o a una capa de preparación como Data Warehouse o Fabric.
Query folding guidance in Power BI Desktop
4. El modelo de datos no está diseñado para análisis
Conectar tablas no equivale a modelar correctamente. Relaciones ambiguas, muchas relaciones bidireccionales, alta cardinalidad innecesaria, columnas de texto extensas o estructuras copiadas directamente desde sistemas transaccionales pueden afectar rendimiento y mantenibilidad.
Para escenarios analíticos, Microsoft continúa recomendando el diseño en esquema estrella, separando tablas de hechos y dimensiones. La razón no es estética: un modelo más claro facilita relaciones eficientes, compresión y cálculos más previsibles.
5. DAX calcula demasiado en tiempo de consulta
Una medida puede devolver el resultado correcto y, al mismo tiempo, consumir más recursos de los necesarios. Iteradores sobre grandes tablas, filtros complejos, medidas encadenadas, lógica repetida o cálculos que podrían resolverse antes en la capa de datos pueden aumentar los tiempos de respuesta.
Aquí conviene distinguir dos preguntas: ¿la lógica debe calcularse dinámicamente porque depende del contexto del usuario? ¿O podría prepararse antes sin perder flexibilidad? No todo debe resolverse con DAX.
6. El modelo creció pero la arquitectura no
Muchos proyectos comienzan pequeños: una fuente, unas pocas páginas y un conjunto acotado de usuarios. Después llegan nuevos años, áreas, tablas, métricas y audiencias. El problema aparece cuando el modelo conserva exactamente la misma arquitectura con la que nació.
BigTelligent documentó un caso técnico en el que un modelo de stock superaba los 2 GB y no era publicable bajo el esquema utilizado. El trabajo combinó mejoras en SQL Server, modelado tabular, Tabular Editor y DAX Studio. El modelo final quedó en aproximadamente 997 MB e incorporó dos años y medio de históricos. La enseñanza es clara: la optimización no ocurrió solo en la visualización.
7. La estrategia de actualización no acompaña el volumen
Actualizar todo el histórico en cada ciclo puede ser razonable en un modelo pequeño y totalmente innecesario cuando los datos crecen. Dependiendo del caso, pueden evaluarse actualización incremental, particionamiento, agregaciones o una arquitectura que separe datos crudos, preparados y curados.
En Microsoft Fabric, por ejemplo, la arquitectura medallion organiza los datos en capas Bronze, Silver y Gold, permitiendo preparar productos de datos optimizados para consumo analítico. Pero adoptar Fabric no es una solución automática: primero hay que demostrar que el problema necesita ese cambio.
8. El problema está en la página del reporte, el gateway o la capacidad
Una página con demasiados visuales genera múltiples consultas e interacciones. Visuales personalizados poco eficientes, tablas con excesivo detalle o diseños que cargan todo al mismo tiempo también pueden degradar la experiencia.
A esto se suman factores de infraestructura: gateway, red, ubicación de las fuentes y capacidad disponible. Microsoft recomienda utilizar Performance Analyzer para medir cuánto tarda cada visual y distinguir el tiempo de consulta del tiempo de renderizado. Query Diagnostics permite investigar lo que ocurre dentro de Power Query.
Cómo diagnosticar un reporte lento sin adivinar
- Medí la experiencia: qué página, visual o interacción es lenta y cuánto tarda.
- Probá la fuente: verificá si la consulta original ya presenta demoras.
- Revisá Power Query: identificá transformaciones costosas y si existe query folding.
- Auditá el modelo: tamaño, cardinalidad, relaciones, tablas y columnas.
- Analizá DAX: detectá medidas costosas y cálculos repetitivos.
- Verificá el proceso de actualización: volumen, frecuencia y estrategia incremental.
- Revisá gateway, red y capacidad cuando corresponda.
- Usá Performance Analyzer y otras herramientas para confirmar el cuello de botella antes de modificar.
Principio de optimización No optimices lo que “parece lento”. Medí qué capa consume tiempo y modificá la parte que realmente genera el cuello de botella.
¿Cambiar a Microsoft Fabric soluciona un Power BI lento?
Puede ayudar cuando el problema requiere una arquitectura diferente para integrar, transformar, almacenar o servir grandes volúmenes de datos. Fabric ofrece una plataforma unificada para varias cargas de trabajo y permite construir modelos curados orientados a BI y otros consumos.
Pero si la causa es una consulta SQL mal escrita, una medida DAX ineficiente o una página con demasiados visuales, migrar la plataforma puede trasladar el problema en lugar de resolverlo. La modernización debe responder a un diagnóstico.
En resumen
Cuando Power BI funciona lentamente, revisá la cadena completa: fuente, volumen, Power Query, query folding, modelo, DAX, actualización, gateway/capacidad y visualizaciones. El dashboard es donde el usuario experimenta el problema, pero no necesariamente donde nace.
La mejor optimización es la que puede explicar, con mediciones, qué se modificó y por qué esa modificación mejora el rendimiento.
Cómo puede ayudar BigTelligent
BigTelligent trabaja sobre toda la cadena de datos: SQL Server, integración, Data Warehouse, Power BI, Microsoft Fabric, arquitectura y optimización. Esto permite abordar los problemas de performance desde una perspectiva integral.
Un diagnóstico puede determinar si la solución está en la base de datos, el proceso de carga, el modelo semántico, las medidas, la infraestructura o el diseño del reporte, evitando cambios costosos que no atacan la causa real.
Preguntas frecuentes
¿Por qué Power BI tarda mucho en actualizar?
Puede deberse a la fuente, al volumen de datos, Power Query, la falta de query folding, el modelo, el gateway, la capacidad o una combinación de factores.
¿Cómo saber qué visual está haciendo lento un reporte?
Performance Analyzer permite medir cuánto tarda cada visual y separar, entre otros componentes, el tiempo asociado a consultas DAX y al renderizado.
¿Un modelo grande siempre es lento?
No necesariamente. El tamaño influye, pero también el diseño, la cardinalidad, las relaciones, las medidas, el modo de almacenamiento y la arquitectura.
¿Conviene optimizar SQL Server antes de Power BI?
Si SQL Server es la fuente y las consultas son lentas, sí: la base y las consultas forman parte del mismo problema de rendimiento.
¿Migrar a Fabric mejora automáticamente la performance?
No. Fabric puede resolver necesidades de arquitectura y escala, pero primero es necesario identificar dónde se encuentra el cuello de botella.
