Forum Discussion
Lakehouse Table Rows Limit
Hi community,
I wanted to ask opinions on how to handle the table row limit of a Fabric Lakehouse.
For a P1 capacity the table row limit is 1.5 bn rows. That is pretty low for a feature that claims to work with big data.
Are there any recommendations on the scenario where our data exceed this limit?
- If we have a multibillion row table, how to we deal with it?
- If it is our fact table?
- If we break it into smaller tables, will we then be able to create DAX measures to calculate metrics that may need data from all these tables? Like a total sum or count?
- How the performance will be?
Would love to hear your thoughts.
Thanks.
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
4 Replies
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
