DirectLake limitations

Hi rgsalido 

Direct Lake does support very large tables, but it still has hard guardrails that depend on the Fabric capacity SKU. Even on high SKUs (F64/F128), a fact table with 1.5B minute-level rows is at the edge of the supported limit and often won’t load in Direct Lake. When the engine detects too many rowgroups/files or an oversized table, it will either fall back to DirectQuery or simply refuse to load if fallback is disabled.

For this type of workload (telemetry / high-frequency events), the recommended pattern is:

Create an aggregated table (hourly/daily) and use that table in your Direct Lake semantic model.

Keep the raw 1.5B-row minute-level table in the lakehouse and access it via DirectQuery only for detailed pages or drill-through.

Optionally keep dimensions in Import for better performance (composite model).

This pattern aligns with Microsoft’s guidance for Direct Lake: use it for analytical models and aggregated facts, not for raw high-granularity event streams.

So even with Fabric capacity, the best approach is:
Direct Lake for the aggregated table + DirectQuery for the raw detail table.

If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly