Implementing this would make Direct Lake on OneLake a true superset of onSQL, combining its unique benefits with greater query reliability and flexibility.
Currently, when using Direct Lake on OneLake, guardrails are enforced for each table (such as the 1.5 billion rows/F64 limit). When these limits are reached, queries cannot be executed due to memory constraints. This is a significant restriction, especially given the many advantages of building models on OneLake—such as applying OneLake Security and leveraging multi-artifact model creation.
Although this is a common limitation of Direct Lake, in onSQL-based models, this issue was effectively mitigated through Direct Query (DQ) fallback—meaning that when Direct Lake could not handle a query, it would automatically switch to DQ and allow the query to continue.
I propose enabling the same Direct Query fallback mechanism for Direct Lake on OneLake. If a table hits the memory or row limit and the query cannot be executed in Direct Lake mode, the system should automatically fall back to Direct Query.
