What Is Redis? An In-Memory Data Store, Cache, Database, and Streaming Engine

What Is Redis? An In-Memory Data Store, Cache, Database, and Streaming Engine

Redis is a networked in-memory data store built around keys and rich server-side data structures. Applications use it as a cache, shared state store, database for suitable workloads, message broker, streaming engine, search/vector layer, session store, rate limiter, and more.

The easiest way to understand Redis is not as "a faster database," but as a server that keeps an active dataset in memory and lets clients perform useful atomic operations directly on that data.

For example, Redis can increment a counter, add a member to a Set, update a leaderboard score, append an event to a Stream, or expire a session without the application downloading and rewriting an entire object.

Redis in one minute

A client connects to Redis over the network and works with named keys:

user:42:name
session:abc123
cache:product:900
leaderboard:weekly

Each key points to a Redis data type. Common examples are:

String      simple values, counters, binary/text data
Hash        field-value records
List        ordered sequences
Set         unique unordered members
Sorted Set  unique members ordered by score
Stream      append-only event entries
JSON        nested structured documents

Current Redis Open Source also includes specialized capabilities such as geospatial indexes, time series, probabilistic data structures, search, and vector-oriented data types/capabilities.

The application sends commands such as:

SET user:42:name "Asha"
GET user:42:name
INCR page:home:views
SADD online-users user:42
ZADD leaderboard 9500 user:42

Redis executes those operations on the server and returns the result.

Why is Redis called an in-memory data store?

Redis keeps the working dataset in RAM for normal command processing.

That design avoids using a disk-oriented storage path for every read and write, which is one reason Redis is attractive for latency-sensitive workloads.

But "in-memory" does not mean Redis must lose all data on restart.

Redis Open Source can optionally persist data to disk using:

• RDB snapshots
• Append Only File (AOF)
• both RDB and AOF
• no persistence when the data is fully disposable

The right persistence mode depends on whether Redis contains reconstructable cache entries, sessions, important application state, or another workload with stronger recovery requirements.

Redis is more than a simple key-value cache

If Redis only supported GET and SET, it would be much less interesting.

Its major strength is that values can be native data structures with operations defined on them.

Strings

Strings can hold text, serialized data, binary content, or integer values.

SET feature:new-ui enabled
INCR api:requests

Typical uses:

• cache entries
• counters
• flags
• small serialized objects

Hashes

Hashes store fields under one Redis key.

HSET user:42 name Asha plan pro
HGET user:42 plan

They work naturally for record-like data when fields are accessed independently.

Sets

Sets store unique members.

SADD team:7:members user:42
SISMEMBER team:7:members user:42

Useful for:

• exact membership
• uniqueness
• unions and intersections
• tags and temporary relationships

Sorted Sets

Sorted Sets associate every unique member with a numeric score and keep the collection ordered.

ZADD leaderboard 9500 user:42

They fit:

• leaderboards
• rankings
• score-based ordering
• some priority/rate-limiting patterns

Streams

Streams store ordered event entries and can support consumer groups.

They are useful for retained event processing where consumers may need to read entries after they were produced.

Streams are different from Redis Pub/Sub, which is designed for transient fan-out rather than retained replayable history.

Redis commands are usually atomic

Normal Redis commands operate atomically from the perspective of other clients.

Consider a shared counter.

Instead of:

read value
add 1 in application
write value

multiple application instances can call:

INCR quota:user:42

Redis performs the increment as one operation.

This property is useful for shared counters, Set membership, score updates, rate-limit state, and many coordination tasks.

Redis also provides transactions, optimistic locking with WATCH, scripting, and Functions for cases that require more than one simple command, although Redis transactions are not identical to SQL database transactions and do not provide general-purpose rollback semantics.

Keys can expire automatically

Redis can attach a time to live to a key:

SET session:abc123 encoded-session EX 1800

After the expiry, the key is no longer considered live.

TTL-based data is useful for:

• caches
• sessions
• rate-limit windows
• temporary tokens/state
• presence indicators
• idempotency records

Built-in expiration is one reason Redis works well for ephemeral application state: the lifecycle lives with the key instead of requiring a separate cleanup table or job for every temporary record.

Is Redis a database?

Yes, Redis can be used as a database for workloads that fit its data model and memory/durability trade-offs.

But that does not mean it should replace a relational database everywhere.

Redis is particularly comfortable with:

• key-based access
• hot state
• simple atomic operations
• native data-structure operations
• low-latency reads/writes
• expiring data

A relational database such as PostgreSQL or MySQL is generally a better default when the application depends heavily on:

• joins
• foreign-key constraints
• complex relational queries
• durable multi-row business transactions
• large disk-resident datasets

A very common architecture uses both:

PostgreSQL/MySQL = durable business source of truth
Redis            = hot cache / shared ephemeral state / specialized data structure

Neither tool is universally "better." They solve different parts of the system.

Is Redis a cache?

Redis is widely used as a cache, but caching is only one role.

A backend can store data fetched from a slower source:

cache:product:42

The application checks Redis first and queries the original database only on a cache miss.

Redis provides features that fit caching well:

• per-key TTLs
• memory limits
• eviction policies
• fast key lookup
• shared cache state across multiple app instances

But cache correctness still belongs to the application: stale data, invalidation, stampedes, cache-key design, and failure fallback all need to be handled deliberately.

Is Redis a message broker?

Redis provides several messaging-oriented primitives.

Pub/Sub

Publishers send messages to channels; currently connected subscribers receive them.

It fits transient real-time signals such as:

• WebSocket fan-out
• typing/presence events
• cache invalidation notifications

Classic Pub/Sub does not provide a durable backlog for consumers that were disconnected.

Streams

Redis Streams retain ordered entries and support consumer-group workflows.

They fit event processing that needs more durability, replay, or worker coordination than Pub/Sub provides.

Redis can also underpin job-queue libraries, but production job semantics such as retries, acknowledgement, idempotency, visibility timeout, and dead-letter handling should come from a deliberate queue design rather than a naive push/pop loop.

How Redis achieves low-latency command processing

Redis' core command-serving model is mostly single-threaded and event-driven.

Commands are generally executed sequentially through the main execution path, avoiding much of the lock coordination required by heavily multithreaded shared-memory designs.

Redis also uses background threads for some work, and modern versions can use I/O threading for network activity.

The architecture works well when commands are small and bounded. A slow command over a huge collection can delay unrelated clients because normal command execution shares the main path.

That is why production Redis engineering cares about command complexity, value size, collection cardinality, and slow-command monitoring.

What does persistence mean in Redis?

Redis gives you choices rather than one fixed durability mode.

RDB

RDB creates point-in-time snapshots of the dataset.

It is compact and useful for backups/recovery, but data written after the most recent snapshot can be lost after a sudden failure.

AOF

AOF records write operations so Redis can replay them during startup.

Its fsync policy determines part of the performance-versus-durability trade-off.

RDB + AOF

Both can be enabled together.

No persistence

This can be appropriate for a pure cache whose content is safely reconstructed from another source.

Persistence is a workload decision—not something every Redis deployment should configure identically.

How Redis scales and handles high availability

Several mechanisms solve different distribution problems.

Replication

A primary can replicate data to one or more replicas. Redis replication is asynchronous by default.

Replication can support redundancy and selected read-scaling patterns, but replicas by themselves do not provide a full automatic-failover control plane.

Sentinel

Redis Sentinel is used in self-managed non-clustered deployments to monitor Redis instances and coordinate primary failover.

Redis Cluster

Redis Cluster partitions the keyspace across multiple primary nodes using hash slots, allowing the dataset and write workload to be distributed horizontally.

Cluster affects application key design because some multi-key operations require participating keys to reside in the same hash slot.

Do not deploy Cluster automatically just because an application is "production." A single primary with replicas/Sentinel may be simpler when one node comfortably handles the dataset and workload.

Redis 8 changed what "Redis Open Source" includes

Redis 8 unified capabilities that had previously been associated with separate Redis Stack modules into Redis Open Source.

Current Redis documentation lists data types and capabilities including:

• JSON
• search capabilities
• time series
• probabilistic structures
• vector-oriented functionality

That means a modern explanation of Redis is broader than the old mental model of "Strings, Lists, Sets, and a cache."

For version-sensitive features, verify the documentation for the Redis version you actually deploy because newer data types and commands may not exist on older servers.

What license is Redis under now?

Redis licensing changed over recent versions, so old articles can be misleading.

According to Redis' current licensing documentation:

• Redis 7.2 and earlier remain under BSD-3-Clause
• Redis Community Edition 7.4-era releases used RSALv2 / SSPLv1
• Redis Open Source 8 and later are offered under a tri-license: AGPLv3, RSALv2, or SSPLv1

AGPLv3 is the OSI-approved open-source option. RSALv2 and SSPLv1 are source-available licenses with different conditions.

If licensing affects a commercial product or managed-service offering, read the actual current license terms rather than relying on a simplified blog summary.

Redis vs an in-process cache

An application-local cache can be simpler and avoids a network hop.

Use it when:

• data can safely be duplicated per process
• no shared atomic state is needed
• invalidation across instances is unnecessary
• losing the local cache on restart is harmless

Redis becomes more valuable when:

• multiple application instances need the same state
• operations must be atomic across those instances
• TTLs and eviction should be centrally managed
• specialized data structures are useful
• state should survive an individual application process restart

Common Redis use cases

Redis is frequently chosen for:

• application/database caching
• server-side sessions
• rate limiting
• distributed counters and quotas
• leaderboards
• presence and ephemeral state
• Pub/Sub fan-out
• Streams/event processing
• Redis-backed job queues
• geospatial lookup
• time-series workloads
• search/vector retrieval
• semantic caching and AI-oriented state

Each of those use cases has different durability, memory, and failure requirements. "Redis supports it" is only the beginning of the design decision.

When Redis is not a good fit

Redis may be the wrong primary tool when you need:

• large amounts of cold archival data
• complex relational querying
• rich SQL analytics over large historical datasets
• strict relational constraints
• a workload whose full hot dataset cannot economically fit the chosen Redis memory/storage model
• durability semantics that your Redis configuration cannot provide

It is also unnecessary when a low-traffic application already performs well with a single database and has no shared low-latency state problem.

Adding Redis means adding another stateful dependency to secure, monitor, back up where needed, upgrade, and recover.

A practical mental model

Think of Redis as a network-accessible data-structure server for hot state.

Use it when one of its native operations makes the request path substantially cleaner or faster:

Need a simple cached value?     String
Need field-level state?         Hash
Need uniqueness?                Set
Need ranking?                   Sorted Set
Need ordered retained events?   Stream
Need temporary state?           TTL
Need shared atomic counter?      INCR / HINCRBY

Then decide separately:

• whether Redis is authoritative or derived
• how much memory the workload needs
• whether entries may be evicted
• whether persistence is required
• how failures are handled
• whether replication, Sentinel, or Cluster is justified

That is Redis in practical terms: an in-memory server that combines key-based access with powerful native data structures, expiration, optional durability, and distributed deployment options.

Official references

• Redis Open Source overview
• Redis data types
• Redis data-type comparison
• Redis persistence
• Redis licensing