HyperLogLog (HLL) is a probabilistic algorithm that estimates the cardinality of a multiset—the count of distinct elements—using a fixed, sub-logarithmic amount of memory. Unlike exact counting methods that require memory proportional to the number of unique items, HLL achieves remarkable compression by observing the maximum number of leading zeros in the hashed binary representation of each observed element, providing estimates with a typical error rate of only 2%.
Glossary
HyperLogLog

What is HyperLogLog?
HyperLogLog is a probabilistic data structure that estimates the number of unique elements in a massive data stream with exceptional memory efficiency.
This algorithm is foundational in streaming data pipelines and real-time customer segmentation systems where tracking exact unique visitor counts, search queries, or product views across billions of events would be prohibitively expensive. HLL enables efficient computation of metrics like daily active users and unique impression frequency directly within stream processors such as Apache Flink, allowing for instant, memory-safe COUNT DISTINCT operations on infinite data streams.
Key Features of HyperLogLog
HyperLogLog (HLL) is a probabilistic data structure that estimates the number of distinct elements in a multiset with remarkable memory efficiency. It achieves this by hashing elements and observing patterns in the resulting bit strings, trading perfect accuracy for a fixed memory footprint of just a few kilobytes regardless of data volume.
Constant Memory Footprint
Unlike exact counting methods that require memory proportional to the number of unique elements, HLL uses a fixed amount of memory—typically 1.5 KB to 12 KB—regardless of whether you're counting thousands or billions of distinct items. This is achieved by storing only the maximum observed rank of leading zeros across a set of registers, never the elements themselves.
- Standard error: 1.04% with 1.5 KB
- High precision: 0.4% with 12 KB
- Memory usage is O(1) relative to cardinality
The Harmonic Mean Trick
HLL improves upon earlier estimators like LogLog by using the harmonic mean to combine observations from multiple registers. This makes the estimate significantly more resilient to outliers. A single register with an unusually high rank won't disproportionately skew the result.
- LogLog used the arithmetic mean, which was sensitive to variance
- The harmonic mean dampens the impact of extreme values
- This innovation reduced error by approximately 30% compared to LogLog
Union and Intersection Operations
HLL sketches are mergeable, meaning you can combine two HLL structures representing different sets and get an HLL for the union of those sets—without ever seeing the original elements. This is critical for distributed systems where data is partitioned across many nodes.
- Union: Take the element-wise maximum of register values
- Intersection: Estimated via the inclusion-exclusion principle using union cardinalities
- Enables distributed distinct counting across thousands of shards with zero data movement
Bias Correction for Small Cardinalities
Raw HLL estimates exhibit non-linear bias when counting small sets (typically fewer than 2.5× the number of registers). Production implementations like Redis and Apache DataSketches apply empirical bias correction tables or switch to exact counting below a threshold.
- Linear counting is used for very small cardinalities
- Pre-computed correction tables compensate for estimator bias
- Ensures accuracy across the full range from zero to billions
Real-World Production Usage
HLL is deployed at massive scale across the industry for real-time analytics where exact counts are unnecessary and memory is constrained.
- Redis: Built-in
PFADD,PFCOUNT,PFMERGEcommands - Apache DataSketches: Theta and HLL sketches for streaming systems
- Presto/Trino:
approx_distinct()function for interactive SQL queries - Google BigQuery:
APPROX_COUNT_DISTINCT()for petabyte-scale analytics - Cloudflare: Counting unique IP addresses across their global network
Error Bounds and Confidence
HLL provides probabilistic guarantees on estimate accuracy. The standard error is approximately 1.04 / sqrt(m), where m is the number of registers. This means you can tune the precision-memory tradeoff precisely for your use case.
- Error follows a near-Gaussian distribution
- 95% confidence interval: approximately ±2× the standard error
- Increasing registers by 4× halves the error rate
- The estimate is unbiased after correction
Frequently Asked Questions
Clear, technically precise answers to the most common questions about the HyperLogLog probabilistic data structure and its role in real-time cardinality estimation.
HyperLogLog is a probabilistic data structure that estimates the cardinality—the number of unique elements—of a multiset using a fixed, sub-logarithmic amount of memory. It works by hashing each observed element and observing the pattern of leading zeros in the resulting binary hash. The core insight is that a hash value with a long run of leading zeros is a statistically rare event; the longest observed run of leading zeros across all hashed elements serves as an estimator of how many unique items have been seen. Specifically, if the maximum leading zero count observed is n, the algorithm estimates approximately 2^n distinct elements. To improve accuracy and reduce variance, HyperLogLog splits the input stream into multiple registers using the first few bits of the hash, computes an estimate per register, and then applies a harmonic mean across all registers, correcting for systematic bias using a constant derived by Flajolet et al. This enables cardinality estimation with a typical error rate of 1–2% while using only a few kilobytes of memory, regardless of the true cardinality being in the millions or billions.
HyperLogLog vs. Other Cardinality Methods
A technical comparison of HyperLogLog against exact counting and alternative probabilistic data structures for estimating unique elements in massive data streams.
| Feature | HyperLogLog | Exact Counting (HashSet) | Linear Counting | Count-Min Sketch |
|---|---|---|---|---|
Primary Use Case | Unique element count estimation | Precise distinct count | Unique element count estimation | Frequency estimation per element |
Memory Complexity | O(1) ~1.5 KB for standard error | O(n) proportional to unique elements | O(k) where k is bitmap size | O(w × d) width × depth array |
Query Type | Cardinality only | Cardinality + membership | Cardinality only | Point query frequency |
Supports Element Lookup | ||||
Supports Merging Sets | ||||
Standard Error Rate | 0.81% to 2% | 0% | 1% to 10% | N/A (frequency error) |
Memory for 1 Billion Uniques | ~1.5 KB | ~8 GB | ~100 KB to 1 MB | ~1 MB to 10 MB |
Insertion Speed | O(1) constant time | O(1) amortized | O(1) constant time | O(d) per hash function |
Deletion Support |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Explore the foundational algorithms and stream processing concepts that work alongside HyperLogLog to enable real-time cardinality estimation and unique user counting at massive scale.
Count-Min Sketch
A probabilistic sub-linear space data structure used to estimate the frequency of events in a data stream. While HyperLogLog counts distinct elements, a Count-Min Sketch tracks how many times each element appears.
- Provides frequency estimates with one-sided error
- Used for identifying heavy hitters in clickstream data
Windowed Aggregation
A stream processing operation that computes a summary statistic over a finite, time-bounded subset of an infinite event stream. Merging HyperLogLog sketches within a tumbling or sliding window provides approximate unique counts for specific time intervals.
- Tumbling windows: fixed, non-overlapping intervals
- Sliding windows: overlapping intervals for smoother trends
Cardinality Estimation
The core problem HyperLogLog solves: estimating the number of distinct elements in a multiset without storing every element. This is critical for counting unique visitors, distinct SKUs viewed, or unique search queries in real-time without massive memory overhead.
- Typical error rate of 2% using only 1.5 KB of memory
- Enables sub-second distinct counts on petabyte-scale data

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us