ClickHouse vs BigQuery: Analytical Database Comparison for 2026

At 11:47 PM on a Tuesday, an e-commerce platform serving 2.3 million daily active users hit a wall. Their PostgreSQL primary was at 98% CPU. Every product page load triggered 14 separate database queries — catalog lookups, inventory checks, session reads, and recommendation fetches — all hitting the same server. The on-call engineer had one hour before the EU market opened and traffic doubled. The fix was already in their stack, unused: a Redis 7 cluster deployed six months earlier for session storage and never extended beyond that single use case.

By 2 AM, four of those 14 queries were routed to Redis with a cache-aside pattern and a 300-second TTL. Database CPU dropped to 41%. By the following weekend, they had added Redis-backed rate limiting on their promotions API, a BullMQ job queue for order processing emails, and pub/sub fan-out for real-time inventory updates. The same Redis instance that was handling sessions at 2% utilization was now carrying a third of their application's data workload.

Redis is not a single-purpose tool. This guide covers the five production use cases that deliver the highest leverage — caching, rate limiting, pub/sub and streams, job queues, and session storage — with real Redis commands, eviction and persistence trade-offs, and the gotchas that cause production incidents.

Background

Redis is an in-memory data structure server. That single sentence explains both its performance characteristics and its design constraints. Because all data lives in RAM, reads and writes are measured in microseconds — typically 0.1ms to 1ms for single-key operations at any reasonable QPS. Because RAM is finite and expensive, Redis is optimized for working sets, not full datasets.

The key insight is that Redis is not a replacement for a relational database. It is a complement: fast, ephemeral (or semi-durable), and purpose-built for the operations that relational databases do slowly — random key lookups, TTL-based expiry, atomic counters, and fan-out messaging.

Redis Data Structures

Understanding which data structure to use for each use case is the foundation of effective Redis usage. Using the wrong structure is the most common mistake in Redis implementations.

Strings

The simplest structure: a single key maps to a single byte sequence up to 512 MB. Used for counters (INCR), cached serialized objects, and simple flags. Operations: SET, GET, INCR, INCRBY, SETNX, SET EX.

Hashes

A map of field-value pairs under a single key. The natural fit for structured objects like user sessions or cached database rows. More memory-efficient than storing each field as a separate string key when the hash has fewer than 128 fields. Operations: HSET, HGET, HGETALL, HDEL, HEXPIRE (Redis 7.4+).

Lists

A doubly-linked list of strings. Used for queues (LPUSH/BRPOP), activity feeds, and recent-item buffers. Push to head or tail in O(1). Operations: LPUSH, RPUSH, LPOP, RPOP, BRPOP, LRANGE.

Sets

An unordered collection of unique strings. Used for unique visitor counting, tag indexing, and set operations (union, intersection, difference). Operations: SADD, SMEMBERS, SINTER, SUNION, SISMEMBER.

Sorted Sets (ZSets)

A set where every member has a floating-point score. Members are kept sorted by score. Used for leaderboards, sliding-window rate limiting, delayed job queues, and priority queues. Operations: ZADD, ZRANGEBYSCORE, ZREMRANGEBYSCORE, ZCARD.

Streams

A persistent, append-only log with consumer groups. Used as a durable message queue or event bus. Each entry has an auto-generated ID and arbitrary field-value pairs. Operations: XADD, XREAD, XREADGROUP, XACK, XLEN.

Bitmaps and HyperLogLog

Bitmaps (SETBIT / GETBIT) store per-user boolean flags in extremely compact form — 1 bit per user ID means 100 million users fit in 12.5 MB. HyperLogLog (PFADD / PFCOUNT) estimates the cardinality of a set with ~0.81% error using only 12 KB of memory — ideal for unique visitor counts at scale.

Use Case 1: Caching

Caching is the most common Redis use case and the one with the highest immediate return. The pattern is cache-aside (also called lazy loading): check Redis first, fall back to the database on a miss, write the result to Redis with a TTL, and return it.

Basic Cache-Aside with SET EX

# Write a cached product object (TTL = 300 seconds)
SET product:42 '{"id":42,"name":"Widget Pro","price":29.99,"stock":143}' EX 300

# Read — returns the JSON string or nil on miss
GET product:42

# Atomic set-if-not-exists (prevents cache stampede in single-instance setups)
SET product:42 '{"id":42,...}' EX 300 NX

# Check remaining TTL
TTL product:42
# 287

Eviction Policies

When Redis reaches its maxmemory limit, it must evict keys to make room. Choosing the wrong policy is a silent correctness bug for non-cache use cases.

# Set eviction policy and memory limit in redis.conf
# maxmemory 4gb
# maxmemory-policy allkeys-lru

# Or at runtime (takes effect immediately, not persisted across restarts)
CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lru

# Verify
CONFIG GET maxmemory-policy

Keyspace Notifications

Redis can emit pub/sub messages when keys expire or are modified. This enables cache invalidation patterns where application code subscribes to expiry events and proactively refreshes the cache before the next request misses.

# Enable keyspace notifications for expired events (in redis.conf or at runtime)
CONFIG SET notify-keyspace-events Ex

# Subscribe to expiry notifications for all keys in database 0
# (run in a separate redis-cli session)
SUBSCRIBE __keyevent@0__:expired

Use Case 2: Rate Limiting

Redis is the standard backend for API rate limiting because atomic increment and TTL expiry happen in a single round-trip without application-level locking.

Fixed Window with INCR + EXPIRE

# Rate limit key: user 1001, current minute window
# Key format: ratelimit:{user_id}:{window}

# On each request:
INCR ratelimit:1001:2024021422
# Returns the new count (e.g., 47)

# Set TTL on first increment only (EXPIRE is a no-op if key already has a TTL)
EXPIRE ratelimit:1001:2024021422 60

# Check limit before allowing request:
# If count > 100, reject with 429 Too Many Requests

Sliding Window with Sorted Sets

# Sliding window rate limiter using a sorted set
# Score = timestamp in milliseconds, member = unique request ID (UUID or timestamp+random)

# Current time in milliseconds
SET current_time_ms 1708617600000  # (computed in application)

# Add the current request to the sorted set
ZADD ratelimit:sliding:1001 1708617600000 "req_a1b2c3d4"

# Remove all requests outside the 60-second window
ZREMRANGEBYSCORE ratelimit:sliding:1001 0 1708617540000
# (current_time_ms - 60000)

# Count remaining requests in the window
ZCARD ratelimit:sliding:1001
# Returns 47 — if >= 100, reject request

# Set TTL to auto-expire the key when idle
EXPIRE ratelimit:sliding:1001 120

GCRA / Redis Cell Module

For production-grade rate limiting, the redis-cell module implements GCRA (Generic Cell Rate Algorithm) in a single CL.THROTTLE command. It handles burst capacity, per-request cost, and returns remaining quota and retry-after headers in one atomic operation. If your Redis deployment supports modules (self-hosted or Redis Stack), this is the preferred approach over manual sorted-set implementations.

Use Case 3: Pub/Sub and Streams

Redis pub/sub enables fan-out messaging where a single publisher sends a message and all active subscribers receive it. The canonical use case is broadcasting real-time events — inventory updates, live score feeds, chat messages — across multiple application instances without polling.

Basic SUBSCRIBE / PUBLISH

# Subscriber (run in one terminal / connection)
SUBSCRIBE inventory:updates

# Publisher (run in another connection)
PUBLISH inventory:updates '{"product_id":42,"new_stock":118,"timestamp":1708617600}'

# Pattern subscribe — receive messages on any matching channel
PSUBSCRIBE inventory:*

Redis Streams as Durable Pub/Sub

Redis Streams are an append-only log with consumer groups. Each message is persisted until explicitly deleted. Consumers can read from any point in the stream, and consumer groups enable competing-consumer fan-out where each message is delivered to exactly one consumer in a group.

# Producer: append a message to the stream
# * means auto-generate the ID (timestamp-sequence)
XADD order:events * order_id 90123 status "placed" user_id 1001 total 149.99
# Returns: "1708617600123-0"  (stream entry ID)

# Consumer: read new messages (blocking, 5-second timeout)
XREAD COUNT 10 BLOCK 5000 STREAMS order:events $

# Create a consumer group starting from the beginning of the stream
XGROUP CREATE order:events email-workers $ MKSTREAM

# Read as a consumer group (delivers each message to only one worker)
XREADGROUP GROUP email-workers worker-1 COUNT 5 BLOCK 5000 STREAMS order:events >

# Acknowledge a processed message (removes it from the pending-entries list)
XACK order:events email-workers 1708617600123-0

# Check stream length
XLEN order:events

# Trim stream to keep only the last 10,000 entries
XTRIM order:events MAXLEN ~ 10000

Use Case 4: Queues and Job Processing

Redis lists provide a simple, reliable queue primitive. LPUSH adds jobs to the head; BRPOP blocks workers waiting for jobs from the tail — giving FIFO order, zero polling overhead, and sub-millisecond delivery latency.

Simple LPUSH / BRPOP Queue

# Producer: enqueue a job
LPUSH jobs:email-notifications '{"type":"order_confirmation","order_id":90123,"user_email":"alice@example.com"}'

# Worker: block for up to 30 seconds waiting for a job
# Returns: ["jobs:email-notifications", "{...}"] or nil on timeout
BRPOP jobs:email-notifications 30

# Check queue depth
LLEN jobs:email-notifications

# Peek at the next job without consuming it
LINDEX jobs:email-notifications -1

Delayed Jobs with Sorted Sets

For jobs that should run at a future time — scheduled emails, retry backoff — store them in a sorted set with the execution timestamp as the score. A polling worker checks for jobs whose score is in the past.

# Schedule a job to run at Unix timestamp 1708621200 (1 hour from now)
ZADD jobs:delayed 1708621200 '{"type":"subscription_reminder","user_id":2042}'

# Worker: atomically fetch and remove all jobs due now
# (use ZRANGEBYSCORE + ZREM in a Lua script for atomicity)
ZRANGEBYSCORE jobs:delayed 0 1708617600  # jobs with score <= now

# Remove fetched jobs
ZREMRANGEBYSCORE jobs:delayed 0 1708617600

Use Case 5: Session Storage

Session data needs to survive across multiple application servers, expire automatically, and be readable in a single key lookup. Redis hashes with TTLs are the textbook fit: structured, fast, and self-cleaning.

Session Key Convention and HSET with TTL

# Key naming convention: session:{session_token}
# Use a cryptographically random session token as the key suffix

# Create a session (set multiple fields atomically)
HSET session:abc123xyz user_id 1001 role "admin" cart_id 7891 created_at 1708617600

# Set TTL: session expires after 30 minutes of inactivity
EXPIRE session:abc123xyz 1800

# Read a single session field
HGET session:abc123xyz user_id
# "1001"

# Read all session fields at once
HGETALL session:abc123xyz
# 1) "user_id"
# 2) "1001"
# 3) "role"
# 4) "admin"
# 5) "cart_id"
# 6) "7891"
# 7) "created_at"
# 8) "1708617600"

# Extend the TTL on activity (sliding expiry)
EXPIRE session:abc123xyz 1800

# Invalidate session on logout
DEL session:abc123xyz

Persistence for Session Storage

Sessions cannot be safely lost on restart — users would be unexpectedly logged out. Enable AOF (Append Only File) persistence for session-storage Redis instances:

# In redis.conf
# appendonly yes
# appendfsync everysec    # fsync every second — good balance of durability and performance
# auto-aof-rewrite-percentage 100
# auto-aof-rewrite-min-size 64mb

# Verify AOF is active
CONFIG GET appendonly
# 1) "appendonly"
# 2) "yes"

# Check AOF rewrite status
INFO persistence
# aof_enabled:1
# aof_rewrite_in_progress:0
# aof_last_rewrite_time_sec:3

RDB vs AOF: Choosing Per Use Case

Working with JusDB on Redis

JusDB manages Redis deployments for engineering teams who need production-grade reliability across all five use cases — caching, rate limiting, pub/sub, queues, and session storage — without building and maintaining the operational layer themselves. Our DBAs handle cluster configuration, eviction policy tuning, AOF and RDB persistence setup, memory sizing, replication topology, keyspace notifications, and 24/7 incident response.

We also regularly audit existing Redis deployments where teams have grown beyond a single-use-case setup and hit the policy conflicts described above: a cache instance that is silently evicting session keys under load, a job queue that is losing work on restarts because persistence was never configured, or a pub/sub implementation that should have been Streams six months ago.

Explore JusDB Managed Database Services →  |  Talk to a DBA

Related reading:

• Redis vs Valkey: A Complete Guide to the Future of In-Memory Databases
• Redis Performance Tuning: Optimizing Redis for High-Traffic Workloads
• Read Replicas vs Caching: When to Use Each