Here is an interesting use case of HyperLogLog you probably have not seen before - predicting whether adding more RAM to your database will actually help.
I was going through Neon’s engineering blog and found that their autoscaler uses HLL to estimate the Working Set Size (WSS) of a database. It counts unique data pages accessed over time and, from that estimate, decides whether scaling up memory actually makes sense.
Quick background, if you are unfamiliar: WSS is the amount of data actively being accessed during a given time window. If your database is 1 TB but only 5 GB is being queried regularly, you do not need massive memory - just enough to hold that 5 GB working set.
This is where HLL fits in nicely. Instead of tracking every unique page exactly (which is expensive in both memory and CPU), HLL gives you an approximate count of distinct pages accessed with very low memory usage (a few KB), fixed space regardless of input size, and error rates around 1-2%.
Over a sliding time window, the system observes page accesses, feeds page IDs into an HLL, and gets an estimate of unique pages accessed - that is your approximate WSS.
The scaling logic is now simple: if the WSS fits in the local file cache, more RAM helps. But if the workload is too large, adding memory changes nothing - you end up paying for resources that cannot move the needle on cache hit rate.
So what it answers is this one interesting question - “Will this memory actually be used by hot data, or is it wasted?”
Probabilistic data structures are fun, ngl - somehow I keep finding them in the least expected places :)