17 September 2026 · 8 min
Capacity is not a feeling
Microsoft Fabric sells the idea that OneLake plus Direct Lake means Power BI is always current. In practice the SKU is a shared pool. A semantic model that scans a wide view, a notebook that retries, and a pipeline that overlaps the board pack are all the same CU meter. We have walked into estates where 'F8 should be plenty' and found three workspaces bursting overnight because a Direct Lake table still pointed at a SQL view with a DISTINCT.
The first save is almost always: stop treating Direct Lake as a free import mode. Measure the CU, name the owner of each workspace, and put a cap on background operations during the working day. One public-sector client cut the monthly Fabric overage by more than half without losing the 15-minute refresh they actually needed.
Direct Lake views that lie
Direct Lake likes Delta tables with a clean key, V-Order, and stats that match what the model thinks. Put a view in the middle - especially one that unions history, filters 'latest', or hides duplicates - and you get: wrong grain, extra partitions scanned, and a refresh that looks green while the visual is a day behind.
We flatten the grain in the lake. One table, one grain, documented in the catalogue. The model reads the table. The view, if it must exist, is for humans, not for the semantic model.
Duplicates, schedules, node choice
Duplicates are not a Power BI problem. They are a load problem: two pipelines writing the same business key, a late file, a MERGE without a watermark. Fabric will happily store both rows. The dashboard will double the revenue. The schedule that 'runs every 5 minutes' then collides with itself.
Pick the smallest node that finishes inside the window. F64 for a tidy 200GB model is how money leaves. Spark sessions that cold-start for a 40-second job are how CU disappears. We schedule the heavy lifts off the live dashboard path, keep a thin gold table for near-live, and refuse overlapping runs with a lock in the pipeline.
Related service: Cloud data