Beyond the core types, Redis offers several specialized structures that solve specific problems very efficiently. The HyperLogLog is a probabilistic counter for unique items. Regardless of how many distinct items have been added, it occupies a fixed footprint of about 12 KB per key and has a typical standard error of around 0.81%. Both PFADD and PFCOUNT run in constant time, \(O(1)\), per key. HyperLogLogs are ideal for daily unique visitor counts, distinct query counts, or counting distinct IP addresses, where exact cardinality would be far too expensive to track.
Bitmaps are ordinary Redis strings interpreted as arrays of bits, addressable by index. SETBIT sets a single bit at a given offset, GETBIT reads it, and BITOP performs bitwise AND, OR, XOR, and NOT across multiple keys in a single operation. These structures are extremely compact and very fast for tracking per-user boolean state across days, for daily active user analytics, or for feature flags where each user is simply a bit in a long string of bytes.
The geospatial index is a sorted set in disguise. Locations are stored in a sorted set where the score is a 52-bit geohash encoding of the latitude and longitude, which is what makes range queries by position possible. GEOADD adds a location, and GEOSEARCH, introduced in Redis 6.2 to replace the older GEORADIUS, returns places within a given radius of a point. GEODIST computes the distance between two members of the index. The complexity of GEOSEARCH is roughly \(O(N + \log M)\), where N is the number of items in the radius and M is the total number of items in the index. Finally, Bloom filters provide a probabilistic membership test with possible false positives but no false negatives; in Redis they are delivered by the RedisBloom module as either Bloom or Cuckoo filters. Their main use is to avoid expensive downstream lookups for items that are very likely absent, such as checking whether a username or cache key exists before hitting a backing database.