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.
... View more
The GIT approach is our suggested approach when version control is required. GIT brings a number of capabilities that do fit perfectly with the task of handling version control.
Would you mind sharing more about what sort of scenarios or challenges you're facing today that cannot be addressed with git? Or perhaps what scenarios could only be addressed by having a JSON export of the Dataflow definition?
Please do bare in mind that you can also leverage the REST API today to get the full Dataflow definition without ever setting up GIT for your workspace:
https://learn.microsoft.com/en-us/rest/api/fabric/dataflow/items/get-dataflow-definition