Valkey

What is Valkey?

Valkey is the community continuation of Redis, covering the same in-memory key-value workload: caching, session storage, rate limiting, queues and pub/sub. Drop-in compatible with clients written for Redis.

Best for

Caching and short-lived data in front of a slower database

Why choose Valkey

Valkey is the community continuation of Redis, created when the original project changed its license. For almost every practical purpose it is the same product: the same in-memory data structures — strings, hashes, lists, sets, sorted sets and streams — the same command set, the same protocol, and client libraries written for Redis work unchanged. It occupies the role that sits in front of a slower database: caching query results and rendered fragments, holding sessions, backing rate limiters, running job queues and pub/sub. Because everything lives in memory, operations are measured in microseconds, which is what makes it worth the operational cost of running a second data store. For anyone who wants the Redis workload without the licensing history, it is the straightforward answer.

Replaces

• Redis Enterprise
• Amazon ElastiCache
• Memcached

Key features

• Wide range of data structures
• Pub/sub and streams
• Persistence via snapshots and append-only file
• Redis protocol compatibility

What to watch out for

Everything lives in memory, which means your dataset must fit in RAM and the cost per gigabyte is far higher than disk. Persistence exists but is a compromise: snapshotting can lose the most recent writes, append-only logging is more durable but slower, and neither gives you the transactional guarantees a real database provides. It is not a general-purpose database, and applications that treat it as one end up with data loss they did not anticipate. Running it without authentication on a reachable address is one of the most common ways a server is compromised, and the attack usually involves writing to disk through a persistence misconfiguration. Cluster mode and replication add real complexity, and pub/sub delivery is fire-and-forget with no acknowledgement.

How to deploy

• Docker with a persistent volume if persistence matters
• Require a password and bind to a private interface
• Set a memory limit and eviction policy

Getting started

Bind it to an internal interface, enable authentication and never expose the port publicly — this is not optional. Decide your persistence strategy explicitly, because the default differs between use cases and losing a cache is fine while losing a queue is not. Set a memory limit and an eviction policy so it fails predictably rather than by triggering the system's out-of-memory killer. Give each application its own logical database or key prefix so one can be flushed without disturbing another. Monitor memory and eviction counts, since eviction is silent by design and can look like unexplained application slowness.

Typical setup

A single instance bound to an internal interface with authentication enabled, never a public port. Persistence is chosen deliberately to match the workload — snapshotting where the data is a rebuildable cache, append-only logging where a queue would be painful to lose. A memory limit and eviction policy are set so pressure fails predictably. Each application uses its own logical database or key prefix so one can be flushed in isolation. Memory and eviction counts are monitored, since eviction is silent and presents as unexplained application slowness.

Who should look elsewhere

Do not use it as your primary database for data that must not be lost, because persistence is a best-effort compromise rather than a guarantee. Avoid it if your dataset is larger than the memory you are willing to pay for — the economics turn against you quickly. And if you only need a cache in front of one application that already handles its own in-process caching, adding a networked store introduces a dependency and a failure mode for a performance gain you may not need.

Project health

• GitHub stars: 27,352
• Last code push: 2026-10-01
• Open issues: 912
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.