# RedisBloom probabilistic data types for Redis 8

> RedisBloom adds Bloom filters, Cuckoo filters, Count-min sketches, Top-K, and t-digest structures to Redis. It fits memory-sensitive stream workloads, but its approximate results and Redis 8 packaging make it unsuitable for exact accounting or older 32-bit systems.

**RedisBloom/RedisBloom** — Probabilistic Datatypes Module for Redis

- Repository: https://github.com/RedisBloom/RedisBloom
- Website: https://redis.io/docs/stack/bloom/
- Stars: 1,783 · Forks: 269
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/redisbloom-redisbloom

## Why RedisBloom fits memory-sensitive Redis streams

RedisBloom solves a specific storage problem: processing a stream when retaining every item or every exact frequency is too expensive. It offers five probabilistic data structures for different questions about that stream. Bloom filters and Cuckoo filters test whether a value has appeared before. Count-min sketch estimates how often a value has appeared. Top-K identifies frequent values, while t-digest answers distribution questions such as percentile values, rank lookups, counts below a threshold, and means between percentiles.

The intended users are engineers operating Redis workloads where approximate answers are acceptable and memory consumption matters. Membership filtering is one example. A pipeline can ask whether a value was seen without keeping the complete set of observed values. Frequency analysis and percentile estimation serve similar constraints, although each structure has a different accuracy model.

This is not a general replacement for Redis sets, hashes, sorted sets, or exact counters. RedisBloom becomes relevant when the application can decide what an incorrect result means. A false-positive membership result may be tolerable for preliminary filtering. A Count-min sketch error may be unacceptable if it affects billing. Top-K and t-digest also produce approximations, so their acceptance criteria must be defined before they become part of an application path.

The README describes probabilistic structures as a way to reduce memory use substantially compared with accurate algorithms, and as generally faster than those algorithms. It does not provide workload-specific latency or throughput figures, so the exact gain cannot be inferred from the README alone.

## Five RedisBloom structures answer different stream questions

The module is a collection of data structures rather than one Bloom filter implementation. Bloom filters and Cuckoo filters cover related membership queries, but they should not be treated as identical storage schemes. The README groups them because both answer whether value `v` appeared in a stream. It does not document their exact trade-offs or provide a selection rule between them.

Count-min sketch targets frequency estimation. Instead of returning only a membership-style decision, it estimates the number of times `v` occurred. That makes it relevant to repeated-event analysis, provided callers accept sketch-based error and choose capacity and error settings appropriately. The repository description calls memory use and accuracy controllable, but it does not specify recommended parameters for a particular workload.

Top-K answers which `k` values are most frequent. This differs from Count-min sketch because it maintains a frequency-oriented result for a requested set of leading values rather than exposing only an estimate for one queried value. The exact update and eviction behavior is not described in the README.

The t-digest covers distribution analysis. According to the README, it can determine which fraction of values are below a threshold, how many values are below it, return a percentile value, calculate the mean between two percentiles, and find the value at a requested rank from either end. Its scope is therefore wider than a conventional average calculation, but the linked Redis documentation still needs to be consulted for command syntax, serialization, and accuracy configuration.

No module can make an approximate result exact after insertion. If downstream logic requires deterministic accounting, these structures answer a different problem from Redis's exact collection types.

## Redis 8 packaging removes the standalone module requirement

The most important adoption boundary appears before installation. The README states that, starting with Redis 8, all RedisBloom data structures are integral to Redis and do not require separate installation. It also states that standalone RedisBloom releases are no longer being made. The repository remains available, but its current role is tied to the Redis project rather than a separate module that every Redis 8 user must load.

The repository includes source code, tests, documentation, build files, licensing files, and a Dockerfile. Based on that layout, contributors and packagers still have code to build and test. However, the README does not present a complete operator installation guide for obtaining a Redis 8 distribution with probabilistic data types enabled. It directs readers to the Redis data type documentation and the main Redis repository.

The included Dockerfile shows the older standalone-module path. It builds `redisbloom.so`, copies it into `/usr/lib/redis/modules`, and starts `redis-server` with `--loadmodule`. The image defaults to `REDIS_VER=6.2.10`, which is a repository build input rather than a recommendation from the README. Using that file for a new Redis 8 deployment would conflict with the README's statement that separate installation is unnecessary.

RedisBloom supports only 64-bit architectures. The README explicitly says that 32-bit systems are not supported, while the Makefile accepts `x64` and `arm64v8`. This restriction should be checked against the target platform before source builds, packaging work, or deployment planning.

## Building the source tree for development or packaging

For contributors working with the repository rather than installing probabilistic types in Redis 8, the Makefile exposes a bootstrap and build path. `make bootstrap` installs packages required for the build. It provisions the Readies tooling and a Python virtual environment according to the Makefile comments. The exact operating system packages selected by the installer depend on `.install/` and `.install/os/<osnick>.sh`.

The build sequence then prepares dependencies and compiles the module. The following commands come directly from the Makefile help and Dockerfile build sequence. They do not install RedisBloom into Redis 8 because the README says that operation is no longer necessary there.

```bash
make bootstrap
make fetch
make all
```

A completed source build should produce the project artifact used by the standalone packaging path. The Dockerfile copies `redisbloom.so` into `/usr/lib/redis/modules` and runs Redis with `--loadmodule`. That sequence explains the repository's module layout, but it should not be presented as the Redis 8 installation procedure.

The repository also accepts architecture-specific build choices documented by the Makefile. Only `x64` and `arm64v8` pass its explicit architecture check. A first real Redis 8 use should therefore begin with the Redis probabilistic data type documentation linked by the README. The README does not contain the actual Redis commands, command arguments, or a small insertion-and-query example. Reproducing them here without checking that documentation would risk inventing an interface. The project-specific verification point is to confirm that the installed Redis 8 build exposes the documented probabilistic type commands before sending production data.

## Approximate results require application-specific error policy

The central limitation is not a crash or a missing platform feature. It is the accuracy contract implied by the data structures. Bloom and Cuckoo filters answer membership questions probabilistically. Count-min sketch estimates frequencies. Top-K identifies leading frequent values through an approximate structure. t-digest summarizes distributions. The application must decide whether those answers are suitable for each decision it controls.

A false positive can be tolerable in one workflow and unacceptable in another. The same is true for frequency overestimation, an approximate Top-K result, or a percentile that differs slightly from an exact calculation. RedisBloom lowers storage requirements by accepting controlled inaccuracy, as stated in the README. It does not remove that trade-off after the data has been inserted.

Another constraint is the supported architecture boundary. Deployments on 32-bit systems are outside the project scope, and the Makefile rejects architectures other than `x64` and `arm64v8`. This matters for legacy hosts, embedded targets, and some container build paths.

The README is also thin on operational safeguards for these structures. It does not document rollback, backup-specific behavior, memory sizing formulas, persistence compatibility, or recommended failure handling. Those points should not be inferred. The linked Redis documentation is the relevant place to verify command behavior and data lifecycle expectations for the Redis version being deployed.

## Exact Redis collections remain the direct alternative

The clearest alternative is Redis's exact data model rather than another probabilistic library. Redis exact collections may be alternatives when exact answers are required, although the README does not compare their specific features. These structures consume more memory when the dataset is large because they preserve the information needed for exact answers.

The difference is architectural. Exact collections answer from stored values. RedisBloom compresses or summarizes the stream into a probabilistic representation, trading some fidelity for lower memory consumption. A team choosing the exact route accepts storage cost for deterministic results. A team choosing RedisBloom accepts approximate results to avoid retaining every relevant item.

This makes RedisBloom inappropriate as an automatic optimization applied before the application defines error tolerance. It is better suited to preliminary filtering, approximate frequency analysis, approximate leader selection, and distribution summaries where downstream logic explicitly tolerates the documented approximation model. It is the wrong tool when a regulatory record, ledger, deduplication decision, or ranking must be reproduced exactly.

The README does not compare RedisBloom command by command with Redis Sets or Sorted Sets, so this is a choice based on the stated accuracy and memory trade-off rather than a benchmark claim.

## RedisBloom licensing, maintenance, and upgrade boundaries

The repository is not archived, and its last push was on 2026-10-15. Its recent listed releases include `v2.8.24`, `v2.6.32`, and `v2.4.27`, all dated 2026-08-17. The README nevertheless says that standalone RedisBloom versions are no longer released. These statements concern different versioning paths, but they make release-channel selection important.

Starting with Redis 8, the README lists three licensing choices: Redis Source Available License 2.0, Server Side Public License v1, and GNU Affero General Public License version 3. Earlier versions remain subject to the first two options listed for prior versions. The repository metadata classifies the license as custom because GitHub cannot map the arrangement to one standard license identifier.

This is not legal advice. Distribution, modification, and service deployment implications depend on the selected license and the exact version. The files to inspect are `LICENSE.txt`, the `licenses/` directory, and `CONTRIBUTING.md`. The contribution terms stated in the README apply Redis Software Grant and Contributor License Agreement terms to code contributions.

An upgrade decision must also account for the Redis integration boundary. Redis 8 users should verify that probabilistic types are present in their Redis distribution rather than assuming a separately downloaded module is required. Source-based users should inspect `CONTRIBUTING.md`, `SECURITY.md`, the `changelog`, and build changes when moving between branches or packaging the module themselves.

## Conclusion

Adopt RedisBloom when a Redis 8 deployment can explicitly tolerate approximate membership, frequency, ranking, or percentile results and its memory model suits the stream. Do not choose it for exact financial counts, deterministic rankings, or 32-bit deployments. Before adoption, verify the documented error characteristics for the selected data structure against the application's tolerance, then confirm the licensing option under `LICENSE.txt`, `licenses/`, and `CONTRIBUTING.md`.

## FAQ

### Does Redis 8 require RedisBloom to be installed separately?

No. The README states that all RedisBloom data structures are integral to Redis starting with Redis 8, so the module does not need separate installation.

### Which systems does RedisBloom support?

The README says 32-bit systems are not supported. The Makefile permits the 64-bit `x64` and `arm64v8` architectures.

### Can RedisBloom return exact frequency counts?

Count-min sketch estimates how many times a value appeared rather than storing every item for an exact count. Applications must accept its accuracy trade-off.

### What questions can RedisBloom t-digest answer?

The README lists percentile values, counts and fractions below a threshold, means between percentiles, and values at a requested rank from either end of the distribution.

### How is RedisBloom licensed starting with Redis 8?

The README lists RSALv2, SSPLv1, and AGPLv3 as the choices for versions starting with Redis 8. Review `LICENSE.txt`, `licenses/`, and `CONTRIBUTING.md` for the applicable terms.

## Sources

- [Issues](https://github.com/RedisBloom/RedisBloom/issues)
- [Project website](https://redis.io/docs/stack/bloom/)
- [README](https://github.com/RedisBloom/RedisBloom/blob/master/README.md)
- [RedisBloom/RedisBloom on GitHub](https://github.com/RedisBloom/RedisBloom)
- [Releases](https://github.com/RedisBloom/RedisBloom/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/redisbloom-redisbloom