Forum Discussion
Lakehouse Table Rows Limit
Ok thanks for confirming. At the moment yes that is a limit as the directlake feature is (attempting to) paging all the rows into the vertipaq engine cache from the lakehouse table. I don't know whether it is exactly 1.5B rows as there could be a little variance. However if your Fact table is well above that, then yes it may need splitting if you want DirectLake.
You should be able to use a measure to Sum/Count across multiple tables and it should use directlake
You can use Profiler to actually see if a query is using DirectLake or falling back to DQ in your testing.
Learn how to analyze query processing for Direct Lake datasets - Power BI | Microsoft Learn
Ok thanks for confirming. At the moment yes that is a limit as the directlake feature is (attempting to) paging all the rows into the vertipaq engine cache from the lakehouse table. I don't know whether it is exactly 1.5B rows as there could be a little variance. However if your Fact table is well above that, then yes it may need splitting if you want DirectLake.
You should be able to use a measure to Sum/Count across multiple tables and it should use directlake
You can use Profiler to actually see if a query is using DirectLake or falling back to DQ in your testing.
Learn how to analyze query processing for Direct Lake datasets - Power BI | Microsoft Learn
Thanks for your response AndyDDC.
I will accept it as a solution, so far no other alternatives (other than upgrading the capacity) to use Direct Lake with such a table.
In your opinion, how would the performance be if I use such measures?
And performance wise, when splitting the table, does it make sense to create few big tables that will try to approach the 1.5bn row limit, or create many smaller ones?
Thanks for your time.