Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-approximate-distinct-count.mdv1 · history
CurrentApplies to BothUpdated 21 hours agoSource Microsoft Learn ↗

Status: Public Preview (Import and Direct Lake) — behaviour may change.

What it does

APPROXIMATEDISTINCTCOUNT(<column>) returns an estimated count of unique values. It's a faster, lighter alternative to DISTINCTCOUNT when the column has very many values and an exact figure isn't needed.

Key facts

  • Support in Import and Direct Lake storage modes is in preview. The function itself has worked against some DirectQuery sources for longer.
  • Import and Direct Lake (without fallback) use an engine-side HyperLogLog algorithm, with an error rate of roughly 1.6%.
  • In DirectQuery, and in Direct Lake that has fallen back to DirectQuery, it pushes a corresponding aggregation to the source. Listed sources are Azure SQL, Azure Synapse dedicated SQL pool, BigQuery, Databricks and Snowflake.
  • It takes a column reference only, not an expression, but the column can be any data type.
  • It works in measures, calculated columns and calculated tables. It doesn't apply to visual calculations.
  • No rows to count returns BLANK.

When to use / skip

Use it for unique-visitor or unique-order style measures over tens of millions of distinct values, where a 1.6% wobble is invisible to the audience. Skip it for anything that gets reconciled to finance, audited, or compared with another system's exact figure; use DISTINCTCOUNT there.

Configuration decisions

  • Which measures can honestly tolerate an estimate, and whether the report labels them as approximate.
  • Whether to keep an exact twin measure for reconciliation.
  • Whether the model is staying in Import, or heading to Direct Lake or a DirectQuery source where the behaviour differs.

Gotchas

  • On low-cardinality columns it can be slower than DISTINCTCOUNT and use more memory, especially with many group-by groups or high concurrency. It isn't a free upgrade.
  • The estimate isn't additive in the way people hope, so subtotals and totals may not reconcile visibly.
  • Direct Lake fallback silently changes the algorithm to the source's own, so the error profile can differ by day.

Consultant notes

  • The first question from any finance user will be "why doesn't this match the ledger". Settle that in design, not UAT.
  • Benchmark on the real column. The win only shows up at genuinely high cardinality.
  • Preview in Import means don't hang a certified, headline KPI on it yet.

Revisit when Import and Direct Lake support reaches general availability.

Was this accurate?