Bitmaps.

Three primitives address and count bits. SETBIT key offset value sets the single bit at offset to 0 or 1, growing the underlying String as needed; GETBIT key offset reads it; BITCOUNT key counts the set bits — a population count over the whole string, or over a range.

The cost model is the headline: a flag is one bit, and a count is a scan the engine does in hardware popcount steps. A bitmap is one boolean across many entities (online:users, a bit per user) or many booleans for one entity (user:5000:features, a bit per feature) — the same two commands, read either way.

Name a bitmap per day and set a player's bit when they act. The day's count is a BITCOUNT; windows roll up with BITOP:

BITOP OR over a week's daily bitmaps is weekly-active; BITOP AND over them is "active every day". Retention cohorts fall out of the same two operators: who was active on day 0 AND day 7.

A bitmap can hold one entity's many booleans, or one boolean across many entities. Feature flags per user — bit positions are features:

Online status is one bitmap, one bit per user: SETBIT online:users 12345 1 on, 0 off, BITCOUNT online:users for how many. For millions of users this costs a fraction of a key-per-user, and time-bucketed keys (online:minute:<ts> with an EXPIRE) give "active in the last five minutes" as a BITOP OR over the recent buckets.

Cohort analysis intersects attribute bitmaps — every segment is one BITOP plus a BITCOUNT:

Two commands address bit ranges beyond a single bit. BITFIELD does atomic read-modify on arbitrary-width fields packed into one key — small counters with overflow control (BITFIELD counters INCRBY u8 0 1 OVERFLOW SAT). BITPOS finds the first set or unset bit (BITPOS users:active 1 — the first active id; BITPOS users:active 0 — the first free slot). And rate limiting with one bit per millisecond uses BITCOUNT over a per-second key, reclaimed by a short EXPIRE.

The reason to reach for a bitmap is the memory table — and its one limitation is the same fact read the other way:

Bitmaps are roughly 400× more memory-efficient than a Set of the same ids — but only over a dense integer id space, because a bitmap allocates memory up to its highest offset:

A sparse id space wastes memory. The source's fixes are: use dense, sequential ids; hash ids to a bounded range and accept collisions; or use a Set. BITOP is also O(N) in the longest input, so very large bitmaps are sharded by id range. This sparse-offset caveat is the whole story of the grounding below.

A bitmap's offset must be a non-negative integer. The Branded Component System already mints one for every entity: a 14-character branded id carries a placement — hash32, the first half of MurmurHash3's fmix64 truncated to 32 bits. The runtime asserts the vector at boot (branded_id.ex, self_check!):

That 32-bit placement is exactly a bitmap bit offset. codemojex ships no bitmap code today — zero SETBIT/BITCOUNT/bitmapist in echo/apps/codemojex/lib/. What follows is a retired spike that never shipped: cm-bitmapist (infra/cm-bitmapist/ until 2026-10-11 — a Go port of Doist's bitmapist4, branded-id-native, on its own Fly machine) would mark each player's daily-active bit at Offset(id) = Hash32(Decode(id)). A page-own codemojex example uses the live brand PLR (player):

Because the branded placement is a hash, the offset lands anywhere in the 32-bit space — sparse, exactly the limitation above. So the spike used roaring bitmaps (compressed bitmaps that store runs, not a flat allocation to the highest offset): the published result for a sparse branded keyspace is on the order of ~129 GB on a plain bitmap versus ~300 MB roaring. The hash32 is also collision-bearing in 32 bits (on the order of N²/2³³ colliding pairs), so distinct counts undercount slightly — a property to state, not assume. Select where a structure sits in the modeling family:

Each dive takes one slice of the bitmap pattern, in order: the flag and its offset, the counting and combining of flags, then the daily-active rollup where the sparse-offset limit decides the structure. Read them in order — the flag first, the aggregates second, the cohorts third.