The Problem With Approximate Distinct Counts In Power BI – And How To Solve It

As you’ve probably seen in the blog post for the September 2026 release of Power BI, Import mode and Direct Lake mode semantic models now support the ApproximateDistinctCount() DAX function. I tested its performance on a Direct Lake semantic model with a 1.4 billion row fact table based on the NYC Taxi sample data and as you would expect, it was a lot faster than doing a regular distinct count in most cases. For example when I asked for the distinct count of values from the Total Amount column by Date, my test query took around 6 seconds, consumed around 82 seconds of CPU time and 206,294 KB of memory:

In comparison, the same query getting an approximate distinct count of values from the Total Amount column only took around 4 seconds and around 48 seconds of CPU time, although interestingly rather more memory – 1,063,476KB.

That’s a pretty good improvement given that distinct count measures are often the cause of slow, expensive (in CU terms) DAX queries.

However, there is one big problem with using ApproximateDistinctCount() in your measures: your end users might not like it. If you go to your boss and say to them “Guess what! Your report is now twice as fast and the only downside is that new approximate distinct counts are only about 1.6% away from the actual values” they will very likely get upset and reply that their numbers have to be totally, 100% correct or they won’t be able to make the right decision. Which of course is probably rubbish because in most cases approximate distinct counts are good enough to make decisions. For example I took the same queries that I was testing above and turned them into two line charts which were indistinguishable to the naked eye:

Are you going to win that argument with your boss though? No.

Does this mean that approximate distinct counts are useless except for the rare scenarios where your end users are sophisticated enough to accept them? Well maybe there is a way to solve this problem and find a compromise. If you create a field parameter that allows end users to switch between seeing approximate distinct counts and distinct counts (making approximate distinct counts the default selection) in your reports then you can at least tell your end users that they can use a slicer to choose whether they see fast but slightly inaccurate results or slower but accurate results:

They can then browse quickly and look for trends using the approximate distinct counts and then, when and if they need to see totally accurate values, they can switch to the distinct count values.