Learning Redis - Bitmaps, Bitfields & Geospatial Indexes

#Introduction

Episode 6 took you through Streams. Now we switch to three structures with a specific use-case focus: Bitmaps, Bitfields, and Geospatial Indexes.

Bitmaps use a string as an array of bits — 1 bit per user for activity tracking, extremely memory-efficient. Bitfields compactly store a series of small integers within a single string. And geospatial indexes let Redis search for nearby locations within a radius — from "restaurants around me" to driver matching for ride-hailing. Let's dissect them.

#Bitmaps: Tracking with 1 Bit per User

#Concept and Basic Operations

A Redis string can be interpreted as an array of bits. Each user gets one bit; the bit position is the user ID. SETBIT and GETBIT set and read that bit:

redis-cli SETBIT dau:2026-08-03 1001 1
redis-cli SETBIT dau:2026-08-03 2002 1
redis-cli GETBIT dau:2026-08-03 1001

SETBIT dau:2026-08-03 1001 1 marks user 1001 as active on that date. GETBIT checks the status. A string key of 8 bits takes only 1 byte — for one million users, the whole bitmap takes only about 125KB. Compare that with storing one million keys!

#BITCOUNT and BITOP

redis-cli BITCOUNT dau:2026-08-03
redis-cli BITOP AND dau:week dau:2026-08-03 dau:2026-08-04

BITCOUNT counts how many bits are 1 — the total active users that day. BITOP AND combines several bitmaps with the AND, OR, XOR, or NOT operators. The resulting dau:week contains 1 bits only for users active on both days — the retention calculation pattern (consistently active users).

#Bitfields: Compact Integers in a Single String

#Storing Many Integers in One Key

BITFIELD packs several integers of type u (unsigned) or i (signed) with a given bit width into a single string. This is very useful for lightweight telemetry or many small counters:

redis-cli BITFIELD sensor:packet SET u8 #0 100 SET u8 #1 200
redis-cli BITFIELD sensor:packet GET u8 #0 GET u8 #1

BITFIELD sensor:packet SET u8 #0 100 SET u8 #1 200 writes two 8-bit unsigned integers: byte 0 with value 100, byte 1 with value 200. GET reads both. #N is a type-based offset (#0 means offset 0). The result: two numbers in one small key, without the overhead of two separate keys.

redis-cli BITFIELD counter:stats INCRBY u8 #0 5

BITFIELD counter:stats INCRBY u8 #0 5 increments the bitfield value atomically. With the OVERFLOW SAT or WRAP options, you can control what happens when the value exceeds the type's limit — for example an 8-bit counter that automatically stops at 255.

#Geospatial Indexes

#GEOADD: Storing Location Points

Redis stores geographic coordinates in a geohash-scored sorted set — which is why all geolocation operations are fast and support radius search:

redis-cli GEOADD locations 106.845 -6.208 "Jakarta"
redis-cli GEOADD locations 110.369 -7.801 "Yogyakarta"
redis-cli GEOADD locations 112.751 -7.289 "Surabaya"

GEOADD locations 106.845 -6.208 "Jakarta" adds Jakarta at longitude 106.845, latitude -6.208. Note the order: longitude first, then latitude.

#GEODIST and GEOSEARCH

redis-cli GEODIST locations Jakarta Yogyakarta km

GEODIST locations Jakarta Yogyakarta km computes the straight-line distance between two members in kilometers. To search for locations within a radius:

redis-cli GEOSEARCH locations FROMLONLAT 106.845 -6.208 BYRADIUS 300 km ASC

GEOSEARCH locations FROMLONLAT 106.845 -6.208 BYRADIUS 300 km ASC finds all locations within a 300 km radius of Jakarta's coordinates, sorted from nearest. GEOSEARCH is the modern replacement for the deprecated GEORADIUS — from now on, get used to GEOSEARCH.

#GEOPOS and GEOHASH

To round out the geospatial toolkit, these two read commands are often useful:

redis-cli GEOPOS locations Jakarta
redis-cli GEOHASH locations Jakarta

GEOPOS returns the stored longitude/latitude coordinates for a member. GEOHASH returns the geohash representation — useful for comparing proximity between locations or sharing data with other systems that use the geohash standard.

#Common Use Cases

• Daily Active Users (DAU): a bitmap per date with a bit per user — cheap and fast to compute.
• Retention analytics: BITOP AND across days for continuously active users.
• Feature flags / permissions: a bitmap for mass on/off status.
• Lightweight telemetry: bitfields for many small counters in one key.
• Nearby search: GEOSEARCH for nearest restaurants, ride-hailing driver matching, and geofencing.

#Summary

Episode 7 equipped you with Bitmaps for memory-efficient tracking, Bitfields for compact integers, and geospatial indexes for location-based search: SETBIT/BITCOUNT/BITOP, BITFIELD SET/INCRBY, and GEOADD/GEODIST/GEOSEARCH.

Key takeaways:

• A Bitmap turns a string into an array of bits; 1 million users only need ~125KB.
• BITCOUNT counts active bits; BITOP combines bitmaps for retention.
• BITFIELD packs many small integers into one key with overflow control.
• GEOADD requires the order longitude then latitude.
• GEOSEARCH replaces GEORADIUS for modern radius search.
• GEOPOS and GEOHASH round out geospatial data reading.
• Use Redis's geohash-sorted set for nearby search and driver matching.

In the next episode, episode 8, we cover Pub/Sub Messaging & Keyspace Notifications — real-time broadcast mechanisms. You'll learn SUBSCRIBE/PUBLISH, pattern-based subscriptions, the fundamental difference between Pub/Sub and Streams, and how to use keyspace notifications for cache invalidation. Let's continue!