What is the difference between Redis and Valkey in 2026?

Redis Inc.'s Redis is now AGPL (after a brief SSPL/RSALv2 detour); Valkey is the Linux Foundation's BSD-3-Clause fork led by senior Redis maintainer Madelyn Olson and backed by AWS, Google Cloud, Oracle, and Ericsson. Performance is roughly equivalent: a recent r/devops benchmark put Valkey 9.0 ahead on pipeline throughput (1.46M ops/s vs Redis 8.4's 1.18M) but Redis ahead on single-op p95 latency. Ubuntu 26.04 LTS ships Valkey as the default redis package.

Is a key-value store the same as Redis?

No. Key-value is the data model (a string key maps to a value). Redis is one implementation of that model — specifically an in-memory data-structure server with sub-ms latency and a rich command surface (lists, sets, sorted sets, streams, JSON, vectors). Many key-value stores are not Redis-compatible (DynamoDB, Workers KV), and many disk-first stores do speak the Redis protocol (BaseKV, KeyDB, DragonflyDB).

When is Redis overkill?

Three patterns: (1) simple config or feature flags that change once a week and could fit in flat KV with HTTP API, (2) large persistent datasets (100s of GB) where RAM cost dominates and access is not latency-critical, (3) low-frequency lookups where data is read once every few minutes. For all three, disk-first KV gives Redis-like ergonomics at 10x-50x lower cost per GB.

Can disk-backed KV stores really replace Redis?

For 80%+ of Redis workloads: yes. Sub-ms latency for warm cache, sub-10ms cold, with the same Redis wire protocol so existing clients (ioredis, redis-py, redis-rs) work unchanged. The remaining 20% — pure-RAM workloads requiring 100K+ req/s sub-ms p99 — should stay on in-memory Redis or Valkey. The migration is a config change, not a rewrite, because the wire protocol is the same.

Does Valkey solve the Redis cost problem?

Partially. Valkey on AWS ElastiCache is roughly 20% cheaper per hour than managed Redis. But Valkey is still RAM-based, so the fundamental cost-per-GB problem (RAM is 10x-50x more expensive than NVMe SSD) remains. For workloads where the working set fits in cache but the long tail does not, neither Redis nor Valkey is the cheapest answer — a disk-first KV is.

DragonflyDB vs KeyDB vs Valkey — which is the best Redis alternative?

DragonflyDB wins on raw throughput (494K small-writes/s vs Redis 452K) and is multi-threaded by design. KeyDB is also multi-threaded but its 6.x line moves slower. Valkey is the safe default if you want maximum Redis compatibility with a community license. All three are in-memory — they compete on Redis's own ground. The bigger win is usually picking the right category (in-memory vs disk-first) for your workload, not picking the best in-memory implementation.

What is RedisGraph's status in 2026?

RedisGraph was deprecated in 2024 and reborn as FalkorDB, a separate open-source project. If your existing workload depends on RedisGraph's Cypher queries, FalkorDB is the cleanest migration. See /articles/redisgraph-deprecated-now-what for the migration walkthrough.

Key-Value Store vs Redis in 2026: Valkey Fork, Disk-First Alternatives, Decision Tree

Redis vs Valkey vs DragonflyDB vs KeyDB after the 2024 license fork, plus the disk-first category (BaseKV, RocksDB-backed) that solves the RAM-cost problem none of the forks address. Real 2026 benchmark numbers and a five-question decision tree.

BaseKV Team•February 1, 2026•8 min read

comparisonredisvalkeydragonflydbkeydbarchitecture

"Redis" has become synonymous with "key-value store" the way "Kleenex" replaced "facial tissue." But Redis is a specific piece of software with a specific cost model. Key-value is the data model. The right question is not "Redis or not Redis" — it is "do I need the specific features Redis charges me for, or can a simpler key-value store do the job for a fraction of the cost?"

In 2026 this question has new weight, because the Redis ecosystem fractured.

The 2026 Redis Landscape

After Redis Inc.'s March 2024 license change (BSD → SSPL/RSALv2), the Linux Foundation forked the project as Valkey, backed by AWS, Google Cloud, Oracle, and Ericsson. Redis Inc. countered with Redis 8.0 (AGPL, May 2025) and then Redis 8.4 in 2026 with vector sets, hash field TTL, and Redis Functions 2.0. Valkey 9.0 shipped its own modules. Ubuntu 26.04 LTS now ships Valkey as the default redis package.

The community has been benchmarking the fork tree, including a recent r/devops post that ran Redis 8.4 vs Valkey 9.0.3 vs DragonflyDB 1.37 vs KeyDB 6.3.4 under identical conditions:

| Benchmark | Redis 8.4 | Valkey 9.0 | DragonflyDB 1.37 | KeyDB 6.3 | |---|---:|---:|---:|---:| | Small-writes throughput | 452 K ops/s | 432 K ops/s | 494 K ops/s | 385 K ops/s | | Hot-reads throughput | 460 K ops/s | 445 K ops/s | 494 K ops/s | 475 K ops/s | | Pipeline throughput | 1.18M ops/s | 1.46M ops/s | 951 K ops/s | 647 K ops/s | | Hot-reads p95 latency | 0.607 ms | 1.191 ms | 0.743 ms | 0.711 ms |

The takeaway: all four are roughly equivalent for general use, but none of them solve the Redis cost problem — they all store data in RAM. If you need disk-first storage at lower cost per GB, none of these forks help; you need a different category of database entirely.

What Redis Actually Is (and Isn't)

Redis is an in-memory data-structure server. The "data-structure" part matters as much as "in-memory" — Redis is not just a key-value cache, it is a server you can teach about lists, sets, sorted sets, geospatial indexes, streams, HyperLogLogs, JSON, vector embeddings, time series, and Bloom filters.

It IS:

Sub-millisecond latency in the hot path (RAM is faster than NVMe by 10–100x).
A rich command surface (300+ commands across data structures).
The default lingua franca for cache, queues, pub/sub, rate limiting, session storage.
An ecosystem — ioredis, redis-py, lettuce, redis-rs all "just work."

It IS NOT:

Durable by default — RDB snapshots and AOF logs exist but are tunable trade-offs, not a default-on behaviour. Most production Redis incidents involve someone discovering the default persistence configuration after the fact.
Cheap at scale — RAM costs roughly 10x–50x per GB what NVMe SSD costs. A 100 GB Redis cluster costs an order of magnitude more than a 100 GB disk-backed store.
A general-purpose database — no joins, no secondary indexes (RediSearch is a paid module), no SQL.
Replacement-fork-free in 2026 — the Redis Inc. vs Valkey split means "Redis" is now ambiguous. Ask which one.

When Redis is Overkill

Three concrete patterns where reaching for Redis costs you money you don't need to spend:

1. Simple config / feature flags

You store 50 KB of configuration that changes once a week. Redis works, but you're paying for reserved RAM you never use, and you've adopted an operational dependency (cluster failover, persistence tuning, ACL configuration) for a use case that a flat-tier KV with HTTP API would handle in 20 lines of code.

2. Large persistent datasets

You have 500 GB of user activity logs that need read access but aren't latency-critical. Putting that in Redis costs $5K–$10K/month in cluster RAM. Putting it on disk-backed KV (BaseKV, RocksDB-as-a-service) costs $50–$150/month for the same access pattern.

3. Low-frequency lookups

Data that's read once every few minutes does not need to live in nanosecond-access memory. Anything you'd cache "just in case" without measuring is a candidate for a cheaper storage layer.

The Three Categories of Redis "Alternative"

Most "alternative to Redis" comparisons conflate three very different categories. Pick by which Redis property you actually want:

Category A: Same shape, different license / governance

Valkey, KeyDB, DragonflyDB. All run in RAM, all speak the Redis protocol, all give you sub-ms latency. Their value proposition is mostly: "Redis without the license risk" (Valkey), "Redis with more cores" (KeyDB, DragonflyDB). They do not solve cost-per-GB.

Pick one of these if you want Redis's performance characteristics but want to avoid Redis Inc.'s licensing surface area.

Category B: Pure cache fragments

Memcached, Elasticache, Cloudflare Cache API. Smaller surface than Redis (no data structures, no pub/sub, no streams) but simpler and often cheaper for pure-cache workloads.

Pick if all you actually do is SET key val EXPIRE seconds. The 90% of Redis that you're not using is dead weight.

Category C: Disk-first KV with Redis-protocol ergonomics

BaseKV, RocksDB-backed stores, FoundationDB layers. These store data on NVMe SSD instead of RAM, which means:

10x–50x cheaper per GB for the cold long tail.
Persistence is the default, not a tuning exercise. Power cord pulled? Data is on disk.
The Redis protocol still works — your ioredis / redis-py / redis-rs clients don't care.
Latency is 2x–10x worse than pure RAM, still sub-ms warm, sub-10ms cold. Wrong choice for 100K+ req/s sub-ms p99; right choice for almost everything else.

BaseKV is the disk-first option that speaks the Redis protocol — designed for the workload where you want Redis-like ergonomics but were never going to use the in-memory speed.

A Quick Decision Tree

Answer these in order:

Do you genuinely need sub-ms p99 at 100K+ req/s? → Yes ⇒ Redis 8.4 / Valkey 9 / DragonflyDB. No ⇒ continue.
Is durability ("data survives a node crash") critical? → Yes ⇒ disk-first KV (BaseKV) or Redis with AOF + replication tuned. No ⇒ any cache.
Is cost predictability worth more than peak throughput? → Yes ⇒ flat-tier disk-first KV. No ⇒ any serverless option (Upstash, Workers KV).
Do you actually use Redis's data structures, or just GET/SET? → Structures ⇒ stay on Redis-protocol-compatible. Just GET/SET ⇒ Memcached works fine.
License sensitivity? → SSPL/AGPL is a problem ⇒ Valkey or BaseKV. Not a problem ⇒ Redis 8.

The Protocol Advantage

The 2026 trend that matters: most "alternative" KV stores now speak the Redis wire protocol natively. That means migration is a config change, not a rewrite. Switching from Redis Inc.'s Redis to Valkey, KeyDB, DragonflyDB, or BaseKV is:

# Before
REDIS_URL=redis://redis-inc.example.com:6379

# After
REDIS_URL=redis://basekv.example.com:6379

…and your ioredis / redis-py clients won't even notice. This is what makes the 2026 KV landscape genuinely competitive — vendor switching cost collapsed from "rewrite" to "DNS change + smoke test."

Conclusion

If you need 100K transactions per second with sub-millisecond latency and rich data structures, stay on Redis 8.4 (or Valkey 9 if license matters). For almost everything else — session storage, queues, cache, config, logs, game-server state, Discord bot data — a disk-first KV with the Redis protocol is the better balance of cost, durability, and ergonomics.

BaseKV gives you the Redis protocol with disk-based durability at a flat-tier price. The wire-compatible part means switching is a config change. The disk-first part means the cold long tail of your data isn't paying RAM prices.