Fast or Fresh Was Never a Real Choice

Every BI architecture used to force the same choice. Import the data into the semantic model and queries fly — but the numbers are only as fresh as the last refresh, and refreshes are expensive enough that "fresh" often means "this morning" at best. Query live against the warehouse and the numbers are always current — but every dashboard interaction becomes a round trip to a system that wasn't built to answer twenty analysts' worth of ad-hoc questions at once. Teams have spent years tuning refresh schedules and caching layers to paper over a tradeoff that, until recently, was just a fact of life.

What changed

Direct Lake mode — the semantic model querying the Delta-Parquet files in the lake directly, without copying them into an import cache and without round- tripping DirectQuery to the warehouse for every click — collapses the tradeoff instead of managing it. The engine reads the lake's native file format directly, keeping import-speed interactivity while staying as current as the lake itself. Nothing about this requires reinventing storage; it requires the query engine getting good enough at reading open table formats that copying the data in first stops being worth the cost.

Why this actually matters operationally

The real cost of the old tradeoff was never the compute — it was the process built around hiding it. Refresh schedules that have to be timed around business hours. Incremental-refresh logic that has to be maintained per-table. A whole category of "why doesn't this number match" tickets that turn out to be two dashboards refreshed twenty minutes apart. Collapsing import versus live doesn't just make dashboards faster; it deletes an entire maintenance surface that used to eat a meaningful slice of a data team's week.

The tradeoff that's still real

This doesn't make governance optional — if anything it raises the stakes. When the semantic model reads the lake directly, the lake's own modeling discipline is the dashboard's data quality. There's no import step left to quietly clean things up, no cached extract acting as a buffer between a messy source table and the number an executive sees. The grain has to be declared correctly and the conformed dimensions have to be right, because there's nowhere left to hide a modeling shortcut.

The practical takeaway

Don't evaluate this as a performance upgrade — evaluate it as a forcing function. If your model is clean, this removes a maintenance tax you've been paying for years. If your model has been leaning on the import step to smooth over grain problems or duplicate rows, direct-on-lake querying will surface that immediately, at full visibility, the first day it's live. That's not a reason to avoid it. It's the fastest, cheapest audit of your data model you'll get this year — take it as the free diagnostic it is before you take it as an architecture decision.

There's a pattern worth naming here: the tooling keeps quietly removing the places a modeling shortcut could hide, and shipping it as a feature. It's the same move as when the platform makes your argument for you — you don't have to win the modeling debate anymore, because the stack keeps conceding it for you.