Direct Lake o Import en Power BI: qué cambia y cuándo elegir

Ni Direct Lake ni Import ganan siempre. Import copia los datos al modelo y da un control conocido; Direct Lake lee tablas Delta desde OneLake sin duplicarlas, pero exige una capacidad de Fabric, tablas bien diseñadas y pruebas de permisos antes de liberar. La elección depende del volumen, la frescura que necesita el negocio, el licenciamiento y cómo se consume el dato.

Qué separa a Import de Direct Lake

En Import, Power BI carga una copia de los datos dentro del modelo semántico. Esa copia se comprime en memoria y responde rápido, pero envejece: refleja el negocio hasta la última actualización programada. Es un modo predecible y muy usado, con la contrapartida de que duplica datos y depende de ventanas de refresco.

Direct Lake cambia el punto de partida. Fabric permite que Power BI consuma datos Delta desde OneLake sin duplicarlos como un import tradicional, lo que afecta cómo pensamos volumen, frescura, permisos y límites de capacidad. La documentación de Direct Lake en Microsoft Learn describe los modos disponibles, sus límites y cómo una consulta puede pasar a DirectQuery cuando el modo Direct Lake no puede resolverla. Por eso no lo tratamos como una palabra mágica, sino como una decisión de arquitectura.

Cómo cambia la frescura y la actualización

Con Import, la frescura la define el calendario de refresco: cada actualización trae una foto nueva del negocio. Cuando los volúmenes crecen o las actualizaciones son muy frecuentes, esas ventanas se vuelven pesadas y caras de mantener.

Direct Lake sirve especialmente cuando hay grandes volúmenes o actualizaciones frecuentes, porque lee las tablas Delta ya existentes en OneLake en lugar de recargar una copia completa. Reduce duplicación, pero a cambio exige diseñar bien las tablas Delta, los permisos y la capacidad. La frescura deja de depender de un refresco del modelo y pasa a depender de cómo y cuándo se escriben esas tablas en el lakehouse. Esa es una diferencia de operación, no solo de rendimiento: cambia quién es responsable de que el dato esté al día.

La seguridad se prueba por ruta de acceso, no por informe

Aquí Direct Lake introduce condiciones que Import no tiene de la misma forma. En Fabric, un usuario puede llegar al dato por informes, modelos, lakehouses, endpoints SQL, Excel, APIs o agentes, así que la seguridad se diseña por identidad, rol, elemento, dato y experiencia, no solo por informe.

En Direct Lake, la identidad efectiva influye en cómo se valida el acceso. La integración de seguridad de Direct Lake explica cuándo el acceso y la fuente cambian el comportamiento de la consulta, incluyendo el uso de SSO frente a una identidad fija y la interacción con la seguridad de OneLake. Semantic RLS y OLS siguen protegiendo dentro del modelo cuando el consumo se canaliza por el modelo semántico, pero no alcanza con asumir que una restricción en el informe cubre todos los caminos. Si te interesa este punto en profundidad, lo desarrollamos en seguridad y RLS en Power BI y Fabric. La regla práctica es simple: probamos los permisos antes de publicar.

Los límites de Direct Lake que conviene conocer antes

Direct Lake requiere una capacidad de Fabric y pruebas por SKU, porque el comportamiento puede variar según el modo, la seguridad y la carga. Además, Direct Lake on OneLake y Direct Lake on SQL no fallan de la misma forma: la variante sobre SQL puede cambiar a DirectQuery, mientras que la variante sobre OneLake puede devolver un error si la seguridad, las vistas o los límites no encajan.

Hay un límite que vale la pena anticipar: no conviene asumir que un modelo Import o compuesto puede recibir una tabla Direct Lake on SQL como un parche. Si el negocio necesita objetivos o escritura operativa visibles al instante en Power BI, Excel o Scorecards, la decisión honesta es elegir entre rediseñar el modelo sobre OneLake y Direct Lake, definir una actualización operativa, o actualizar al consumidor mediante una API. Mezclar modos sin ese análisis suele terminar en un comportamiento difícil de explicar.

Cómo decidir sin prometer un rendimiento universal

No hay una recomendación que sirva para todos los casos. La decisión se evalúa por caso, mirando volumen, latencia deseada, licenciamiento, tipo de consumo, seguridad, forma del modelo y mantenimiento. Import sigue siendo una opción sólida cuando los volúmenes son manejables, la frescura por refresco es suficiente y se quiere un modo muy conocido. Direct Lake gana terreno cuando el volumen o la frecuencia hacen costoso el import y el equipo puede sostener la disciplina de tablas Delta, capacidad y permisos.

Esta comparación vive dentro de una decisión mayor: cómo está construido el modelo semántico que consume el negocio. El modelo semántico como contrato de las métricas es lo que hace que un cambio de modo no rompa las definiciones de negocio. Antes de prometer Direct Lake en producción, la práctica sensata es una prueba de concepto con volumen real, permisos reales y tablas Delta optimizadas.

Qué hacer antes de mover un modelo a producción

Antes de liberar, conviene una prueba de concepto acotada: reproducir el volumen esperado, aplicar los permisos por cada ruta de acceso (informe, endpoint SQL, Excel, API) y medir cómo responde el modo elegido bajo la capacidad disponible. Si el equipo no tiene claro qué fuentes alimentan cada tabla ni cómo se prueban los permisos, ese mapa de fuentes, accesos y responsables es el primer entregable, y es lo que permite decidir el modo con criterio y no por moda.

Acción concreta para tu caso: toma un modelo candidato, lista sus tablas más pesadas y sus rutas de consumo, y arma una prueba de concepto en una capacidad de Fabric que compare Import y Direct Lake con esos permisos reales antes de comprometer una fecha de publicación. Si quieres ver cómo abordamos este tipo de decisiones de arquitectura en un caso real, mira la demo gratuita.