RedisBloom: Commands, Capacity, and Operations

In one line

Redis provides Bloom filters as a native type (Redis 8, RedisBloom module, or valkey-bloom): BF.RESERVE with error rate and capacity, BF.ADD/BF.MADD, BF.EXISTS/BF.MEXISTS, and scaling by expansion. Operate it like any Redis data: capacity planning, persistence, replication, and monitoring with BF.INFO.

0/4 · 0%

Think of it like this

A shared whiteboard in the office corridor instead of a private notebook on every desk. Everyone sees the same list, but you have to walk to the corridor to check it.

Key ideas

01
BF.RESERVE key error_rate capacity [EXPANSION n] [NONSCALING]: create with a target FPR and expected items. Without it, BF.ADD auto-creates with defaults (0.01 error, 100 capacity), which is almost never what you want.
02
Scaling: when a filter reaches capacity, Redis adds a sub-filter (EXPANSION times larger, 2 by default) with a tighter error, like a scalable Bloom filter. NONSCALING returns an error when full instead, useful to catch sizing mistakes.
03
Batch operations: BF.MADD and BF.MEXISTS check or add many items per round trip; BF.INSERT combines create-if-missing with add.
04
Operations: the filter is one Redis key (a big key: 120 MB for 100M at 1%), so it lives on one shard in a cluster, is replicated and persisted like other data, and moves as a whole during resharding. BF.SCANDUMP/BF.LOADCHUNK copy it in chunks.
05
Monitoring: BF.INFO (capacity, size, number of sub-filters, items inserted) and BF.CARD; alert when sub-filters grow (you exceeded capacity) or items approach capacity.

Code & diagrams

redisbloom.redisredis

127.0.0.1:6379> BF.RESERVE bf:products 0.001 120000000 NONSCALING
OK
127.0.0.1:6379> BF.MADD bf:products 1001 1002 1003
1) (integer) 1
2) (integer) 1
3) (integer) 1
127.0.0.1:6379> BF.MEXISTS bf:products 1001 424242
1) (integer) 1
2) (integer) 0
127.0.0.1:6379> BF.INFO bf:products ITEMS
1) (integer) 3
127.0.0.1:6379> BF.INFO bf:products CAPACITY
1) (integer) 120000000
127.0.0.1:6379> MEMORY USAGE bf:products
(integer) 215656024          # ~216 MB for 120M items at 0.1%

# Backup / copy in chunks
127.0.0.1:6379> BF.SCANDUMP bf:products 0
1) (integer) 1
2) "\x01\x00\x00..."

When it breaks

BF.ADD on a key that was never reserved

What you see

Redis auto-creates a filter with capacity 100 and 1% error; it keeps adding sub-filters as data grows, ending up with dozens of layers, slower lookups and more memory than a right-sized filter.

Fix & prevent

Always BF.RESERVE with realistic capacity and error; use NONSCALING to surface undersizing; monitor sub-filter count.

Explain it without notes

What happens when a RedisBloom filter exceeds its reserved capacity?

Practice

Reserve a filter for 1M items at 1%, insert 5M items with scaling on, and inspect BF.INFO.

Trade-offs

↔
Redis-hosted filters are shared and persistent but are single big keys with network latency per lookup.

Done when you can

I can operate RedisBloom filters: reserve, batch, scale, back up and monitor them.

Command Palette