What is Redis?

Redis (REmote DIctionary Server) is an open-source, in-memory data structure store used as a cache, a NoSQL database and a message broker. It keeps its working set in RAM, which puts typical operations in the sub-millisecond range, and it can persist that data to disk so a restart does not start from nothing.

The distinction that matters is in the name: Redis is a data structure store, not merely a key-value store. A traditional key-value database maps a key to an opaque blob of bytes that the server cannot interpret. Redis maps a key to a typed structure — a list, a hash, a sorted set, a stream — and gives you commands that operate on it in place, on the server. Incrementing a counter, pushing to a queue, or adding a member to a leaderboard is one atomic round trip, not a read-modify-write cycle in your application.

That single design decision explains most of what follows: why Redis is used for so many unrelated jobs, and why it is not simply "a faster Memcached".

What Is Redis Used For?

Three roles cover the overwhelming majority of production deployments.

Beyond those, the atomic-operations property makes Redis the default answer for a set of coordination problems that are awkward everywhere else: distributed locks, rate limiting, idempotency keys, and deduplication. For worked examples of each, see 10 Redis use cases and how to build them in Java.

Redis Data Types

Older introductions to Redis describe five data types. That has not been accurate for a long time: bitmaps, HyperLogLog and geospatial indexes have been core for over a decade, Redis 5.0 added streams, and Redis 8.0 folded the previously separate Redis Stack modules into the core distribution. The current set:

The probabilistic types are worth a second look, because they have no equivalent in most datastores. A HyperLogLog counts unique items across billions of entries in roughly 12 KB, with about 0.81% error. That trade — bounded memory for bounded inaccuracy — is often exactly the right one, and it is the kind of thing you only get from a server that understands its own data structures. See Redis data types for the full command surface.

How Does Redis Work?

Redis executes commands on a single thread, in an event loop. This surprises people who expect a high-performance server to be heavily parallel, but it is deliberate and it buys two things.

First, every command is atomic by construction. There is no lock to take and no race condition between a read and a dependent write, because no two commands ever overlap. INCR, SETNX and LPUSH are safe under any amount of concurrency without any coordination on your side — the property that makes Redis useful for locking and counting in the first place.

Second, it removes an entire class of bugs. There is no data race in the storage engine to get wrong, and no lock contention to tune under load.

The cost is that a single slow command blocks everything behind it. An unbounded KEYS on a large keyspace, an expensive Lua script, or a SORT over a large collection will stall every other client. This is the most common way a healthy Redis deployment is made unhealthy, and the reason SCAN exists as the cursor-based alternative to KEYS.

Modern versions are not purely single-threaded in every respect. Lazy freeing (UNLINK) and AOF fsync run on helper threads; snapshotting and AOF rewrite run in a forked child process rather than a thread; and socket I/O and command parsing can be spread across threads by raising io-threads, which defaults to 1. But command execution stays serialized in every configuration, and that is the model to reason about. For more, see Redis architecture.

Redis Deployment Modes

Redis scales through four topologies, each trading operational complexity for resilience. One terminology note first, because it is a common source of confusion: Redis 5.0 replaced slave with replica across its command names and configuration directives — REPLICAOF is now preferred, with SLAVEOF kept as an alias — but the other role is still called master in Redis (masterauth, role:master), and INFO still reports connected_slaves and slave0:. Valkey went further, making primary canonical in its config (primaryauth, primaryuser) while keeping the master names as aliases.

The decision is usually simpler than it looks: Cluster is for when one node is not enough; Sentinel is for when one node is enough but downtime is not acceptable. Cluster shards the keyspace across 16,384 hash slots, which constrains multi-key operations to keys that hash to the same slot — a real design consideration, not a footnote. See Sentinel vs Cluster for the full comparison.

Replication in all modes is asynchronous. A primary acknowledges a write before its replicas have it, so a failover can lose the most recent writes. Redis does not offer strong consistency, and split-brain during a partition is a scenario to design for rather than assume away.

Is Redis Open Source? Redis, Valkey and the 2024 Licence Split

This is now the first question many teams need answered, and a great deal of published material describes a situation that no longer exists.

So: Redis is open source under AGPLv3, and Valkey is open source under BSD 3-Clause. The practical difference is copyleft. AGPLv3 is strong copyleft, and many enterprises maintain blanket policies against AGPL dependencies regardless of whether the obligations would actually be triggered. That policy question — not a technical judgment about the engines — is what moves most teams to Valkey.

Valkey is not the only option teams consider. For the full field of alternatives to Redis — including Dragonfly, KeyDB and Garnet — and what each one gives up in command compatibility, see our comparison.

For a feature-by-feature breakdown, see Valkey vs Redis: a complete 2026 comparison.

Redis vs Memcached

The comparison people reach for first, and the one where the gap is widest.

Memcached stores opaque strings in a flat key space. It has no data structures, no replication and no clustering between servers — sharding is normally the client's job, though a built-in proxy has shipped since 1.6.23 — and no crash-durable persistence, though it can warm-restart from a memory-mapped file after a clean shutdown. It is multi-threaded, so a single instance can use more cores for pure get/set traffic.

If your workload is genuinely "cache a rendered blob under a key, at very high throughput, and losing it all is fine", Memcached is a smaller, simpler thing to run. Every other requirement — atomic counters, queues, leaderboards, TTL introspection, persistence, replication, failover — is a reason to use Redis. See Redis vs Memcached, and for the in-memory data grid comparison, Redis vs Hazelcast and Redis vs Apache Ignite.

Using Redis From Java

The Redis server does not bundle a Java client, so a library is required. Redis publishes and helps maintain two of them — Jedis and Lettuce — and the field divides by philosophy rather than by vendor.

Command-level clients — Jedis and Lettuce — map Java methods onto Redis commands. You call hset, you get HSET. Faithful and thin, but the distributed-systems work remains yours: serialization, lock lease renewal, cluster topology handling, retry semantics.

Redisson maps Redis onto the Java collections and concurrency APIs instead. A Redis hash becomes an RMap that implements java.util.Map; a sorted set becomes an RScoredSortedSet; a lock becomes an RLock implementing java.util.concurrent.locks.Lock.

RedissonClient redisson = Redisson.create(config);

// A distributed Map — java.util.Map, backed by a Redis hash
RMap<String, Order> orders = redisson.getMap("orders");
orders.put("4711", order);

// A distributed lock with automatic lease renewal
RLock lock = redisson.getLock("order:4711");
lock.lock();
try {
    // critical section — the watchdog extends the lease while this runs
} finally {
    lock.unlock();
}

The distinction matters most where the naive implementation is subtly wrong. A distributed lock built on SETNX needs a lease long enough to cover the critical section but short enough to recover from a crashed holder — a trade-off with no good answer. When an RLock is acquired without an explicit lease time, Redisson's watchdog renews it while the holder is alive and lets it lapse when the holder dies. Where correctness matters more than convenience, RFencedLock issues monotonically increasing fencing tokens, so a stalled holder's late write can be rejected rather than silently applied — the failure mode the Redlock algorithm is criticised for not addressing. (Redisson's own RedissonRedLock is deprecated in favour of these.)

Redisson also works unchanged against Valkey, which is one way to defer the licensing decision. To get started, see how to use Redis in Java, or compare clients directly: Redisson vs Jedis and Redisson vs Lettuce.

Redis: Frequently Asked Questions

Is Redis a Database or a Cache?

Both, and the distinction is a configuration choice rather than a property of the software. Configure a maxmemory limit with an eviction policy and per-key TTLs and it behaves as a cache — keys disappear under memory pressure. Configure persistence with noeviction and it behaves as a database: nothing is silently dropped, and writes fail when memory runs out. Using one instance for both is a common mistake, because the eviction policy that protects the cache will happily evict the data you meant to keep.

Is Redis SQL or NoSQL?

NoSQL. Redis has no tables, no schema and no joins, and is queried through commands rather than a query language. It is usually classified as a key-value store, though "data structure store" is more accurate. The Query Engine, folded into core in Redis 8, adds secondary indexing and full-text and vector search over hashes and JSON documents — but it is not SQL.

Does Redis Lose Data on Restart?

Only if persistence is disabled. Redis offers RDB point-in-time snapshots, an append-only file (AOF) that logs every write, or both together. RDB snapshotting is what you get out of the box; AOF stays off until you set appendonly yes, after which its default fsync policy of everysec loses at most about one second of writes. Note that replication is asynchronous regardless, so a failover can lose recent writes even with persistence configured — see Redis persistence.

Why Is Redis So Fast?

Mostly because data lives in RAM, which eliminates disk seeks from the read path. Beyond that: an event-driven single-threaded core with no lock contention, purpose-built data structures with memory-efficient encodings for small collections, and a lightweight protocol. Single-threading is a consequence of the design rather than the cause of the speed — it removes coordination overhead rather than adding parallelism.

What Is the Difference Between Redis and Valkey?

Valkey is a fork of Redis 7.2.4, started by departing Redis maintainers under the Linux Foundation in March 2024 after Redis moved off the BSD licence. They share an origin and the great majority of their command surface, and both are actively developed. The main differences today are the licence — BSD 3-Clause for Valkey, tri-licensed RSALv2/SSPLv1/AGPLv3 for Redis — and packaging: Redis ships JSON, search and the probabilistic types inside the core server, while Valkey keeps equivalents as separately loadable modules (valkey-json, valkey-search, valkey-bloom), distributed together as valkey-bundle.

Can Redis Be Used as a Message Queue?

Yes, in three ways with different guarantees. Pub/Sub is fire-and-forget: a message not delivered to a connected subscriber is gone. A list used as a queue holds messages until a consumer pops one, but a consumer that crashes mid-processing loses the message it took. Streams add consumer groups, per-message acknowledgment and replay, and are the right choice when messages must not be lost. See Redis queue and Redis streams.

Similar terms

• Valkey
• Redis Eviction Policy
• In-Memory Database
• Key-Value Store
• NoSQL Database
• Redis Architecture
• Redis Data Types
• Redis Caching
• Redis Client-Side Caching
• Redis Cluster
• Redis Sentinel
• Redis Replication
• Redis Persistence
• Redis Hash
• Redis List
• Redis Set
• Redis Sorted Set
• Redis Streams
• Redis JSON
• Redis Vector Database
• Redis Pub/Sub
• Redis Queue
• Redis Lock
• Redis TTL
• Redis Search
• Redis Java Client