Cuando empiezas un informe en Power BI, una de las primeras decisiones —a menudo tomada sin pensar en ella— es cómo el modelo va a obtener los datos: traer una copia dentro del archivo (Import) o consultar la fuente cada vez que alguien abre un objeto visual (DirectQuery). Parece un detalle técnico, pero condiciona el rendimiento, la frescura de los datos, el coste e incluso qué funciones de DAX vas a poder usar.
La elección equivocada se nota enseguida: informes que tardan segundos en responder a cada clic, actualizaciones que fallan a mitad de la noche, o números que nunca están lo bastante actualizados para quien los consume. La buena noticia es que la decisión sigue reglas razonablemente claras, siempre que entiendas qué hace cada modo por debajo.
En este artículo comparamos los dos modos de almacenamiento sin romanticismos: cómo funcionan, dónde brilla cada uno, qué límites imponen y cómo combinarlos cuando ninguno, por sí solo, es suficiente. Al final, te quedas con un criterio simple para decidir caso por caso.
Qué cambia entre Import y DirectQuery
La diferencia esencial es dónde viven los datos en el momento en que se consulta el informe. En el modo Import, Power BI lee la fuente, comprime los datos y los guarda dentro del modelo. A partir de ahí, todos los cálculos se ejecutan sobre esa copia local. En DirectQuery no hay copia: cada objeto visual genera una consulta que se envía a la fuente (una base de datos SQL, un data warehouse, etc.) y el resultado vuelve en tiempo real.

Esa distinción explica casi todo lo demás. Import es rápido porque no depende de la fuente en cada interacción, pero se queda con una fotografía de los datos que solo cambia cuando se ejecuta una actualización. DirectQuery está siempre sincronizado con la fuente, pero paga esa frescura con latencia y con una dependencia total del rendimiento del sistema de origen.
Import: datos en memoria con el motor VertiPaq
En el modo Import, los datos se cargan en VertiPaq, el motor columnar en memoria de Power BI. VertiPaq comprime las columnas de forma muy eficiente —es habitual ver tablas de decenas de millones de filas ocupar una fracción de su tamaño original— y responde a consultas analíticas a una velocidad difícil de igualar.
Por eso Import es la opción por defecto para la mayoría de los informes. Tienes acceso al lenguaje DAX completo, a agregaciones rápidas y a una interacción fluida con segmentaciones y filtros. El precio es que el modelo tiene que caber en memoria y que los datos solo reflejan la fuente hasta la última actualización. Los límites de tamaño del modelo dependen de la licencia y de la capacidad —lo que es cómodo en Power BI Premium puede no caber en un plan más modesto.
DirectQuery: consultar la fuente en tiempo real
En DirectQuery, el modelo guarda solo los metadatos —la estructura de las tablas y las relaciones— y no los datos en sí. Cada vez que un usuario interactúa con un objeto visual, Power BI traduce la operación en una consulta contra la fuente. Esto tiene una ventaja evidente: los números están siempre tan actualizados como la base de datos subyacente.
Es el enfoque indicado cuando los datos cambian al minuto (por ejemplo, stock u operaciones), cuando el volumen es tan grande que importarlo no tendría sentido, o cuando hay requisitos de gobernanza que exigen que los datos no salgan de la fuente. A cambio, dependes de la rapidez de esa fuente: si la base de datos está mal indexada o sobrecargada, el informe hereda esa lentitud.
Rendimiento: por qué Import casi siempre gana
En igualdad de condiciones, Import es más rápido. Las consultas se ejecutan contra VertiPaq, en memoria, sin saltos de red y sin competir con la carga transaccional de la fuente. En DirectQuery, cada interacción es una ida y vuelta a la base de datos, y varios objetos visuales en la misma página pueden disparar varias consultas a la vez.
Esto no significa que DirectQuery sea lento por naturaleza. Con una fuente bien optimizada —índices adecuados, tablas de agregación, un data warehouse diseñado para lecturas analíticas— puede rendir de forma perfectamente aceptable. Pero exige un trabajo de ingeniería en el lado de la fuente que Import, en gran medida, te ahorra.
Actualización y frescura de los datos
Aquí los papeles se invierten. En Import, la frescura depende de la frecuencia de actualización que configures —cada hora, algunas veces al día, o lo máximo que permita tu licencia. Entre actualizaciones, el informe muestra la última fotografía. Para muchas decisiones de gestión, eso es más que suficiente.
En DirectQuery, los datos están siempre actualizados por construcción, porque se leen de la fuente en el momento. Si tu pregunta es «¿cuántas unidades tengo en el almacén ahora?», DirectQuery responde con la verdad del instante; Import responde con la verdad de la última actualización. Elegir entre uno y otro es, en el fondo, decidir cuánta desactualización tolera el negocio.
Límites y restricciones de cada modo
DirectQuery trae restricciones que conviene conocer antes de decidir. No todas las funciones de DAX están disponibles, algunas transformaciones en Power Query no son compatibles, y existe un límite práctico en el volumen que cada consulta puede devolver. Por defecto, una consulta en DirectQuery falla si un resultado intermedio supera alrededor de un millón de filas —un freno pensado para evitar consultas que consumirían memoria y tiempo en exceso (en capacidades Premium este límite se puede aumentar).
Import tiene otro tipo de límite: el modelo entero tiene que caber en los límites de tamaño de tu capacidad. Los modelos muy grandes obligan a estrategias como la actualización incremental, las agregaciones o la reducción del detalle. Son problemas distintos, pero ambos moldean la decisión.
Modelos compuestos y modo Dual: lo mejor de ambos
Por suerte, no es obligatorio elegir un modo para el modelo entero. Los modelos compuestos permiten que algunas tablas estén en Import y otras en DirectQuery dentro del mismo informe. El modo Dual va más allá: una tabla puede comportarse como Import o como DirectQuery según la consulta, lo que es especialmente útil en tablas de dimensión compartidas.
El patrón más común combina una tabla de hechos enorme en DirectQuery con dimensiones pequeñas en Import (o Dual), a menudo con tablas de agregación por encima para responder al instante a las preguntas más frecuentes. Es una forma de tener frescura donde hace falta y velocidad donde es posible.
Minicaso: informes lentos en una empresa de retail
Imagina una empresa de retail con unas 200 tiendas que montó un panel de ventas en DirectQuery directamente sobre la base de datos transaccional. A principios de mes, cuando todos abrían el informe al mismo tiempo, cada clic tardaba de seis a ocho segundos y la base de datos operacional sentía el peso de las consultas analíticas compitiendo con las ventas.
El equipo reconfiguró el modelo: pasó los datos históricos de ventas a Import, con actualización cada hora, y mantuvo en DirectQuery solo la tabla de stock en tiempo real, mediante un modelo compuesto. El tiempo de respuesta de los objetos visuales históricos bajó a menos de un segundo, la carga sobre la base de datos operacional desapareció, y el indicador de stock siguió mostrando el valor del momento. Nada mágico —solo el modo correcto para cada tabla.
Coste, mantenimiento y el factor humano
Hay un coste que rara vez entra en la cuenta: el de mantenimiento. Un modelo Import bien diseñado tiende a ser más previsible —se actualiza, funciona, y la mayor parte de los problemas se resuelve dentro de Power BI. Un modelo DirectQuery reparte la responsabilidad: el rendimiento del informe pasa a depender de quien gestiona la base de datos, de los índices, de la carga concurrente y de la red. Cuando algo va mal, la investigación involucra a más gente y más capas.
Esto no es un argumento contra DirectQuery —es un recordatorio de que elegir el modo de almacenamiento es también una elección organizativa. Si no tienes quien afine la fuente, un DirectQuery mal soportado se convierte rápidamente en quejas de usuarios. Si, por el contrario, tienes un equipo de datos sólido y un warehouse cuidado, el coste de mantenimiento de DirectQuery deja de ser un obstáculo.
Cómo elegir: una guía rápida
Como regla general, empieza por Import y solo aléjate de él cuando haya una razón concreta. Estas son las señales que suelen justificar DirectQuery (total o parcialmente):
- Frescura al minuto: el negocio necesita ver los datos prácticamente en tiempo real, y una fotografía cada hora no basta.
- Volumen inasumible: la fuente tiene tantos datos que importarlos no es viable dentro de los límites de tu capacidad.
- Requisitos de gobernanza: por política o regulación, los datos no pueden copiarse fuera del sistema de origen.
- Fuente ya optimizada para lectura: tienes un data warehouse rápido, con agregaciones e índices, listo para aguantar consultas analíticas.
Si ninguno de estos puntos aplica, Import casi con seguridad te dará mejor experiencia con menos esfuerzo. Y cuando un solo modo no resuelve, recuerda que el modelo compuesto existe precisamente para esos casos intermedios.
En la práctica
Import y DirectQuery no son rivales a eliminar, sino herramientas para contextos distintos. Import entrega velocidad y el lenguaje DAX completo a costa de trabajar con una fotografía de los datos; DirectQuery entrega frescura permanente a costa de latencia y de restricciones. La madurez está en saber cuándo encaja cada uno —y en usar modelos compuestos cuando la respuesta correcta es «depende de la tabla».
Antes de decidir, hazte tres preguntas simples: con qué frecuencia cambian los datos, de qué volumen hablamos, y cómo de rápida es la fuente. Las respuestas casi siempre apuntan al modo correcto. Elige con intención, no por costumbre, y tu informe te lo agradecerá —en cada clic.