Redis and Key-Value Stores in 2026: The Post-License-Change Landscape

In March 2024, Redis Inc relicensed Redis from the permissive BSD-3 license to a dual SSPL/RSAL model, and the open-source world rearranged itself in response within weeks. By 2026 the practical situation has settled: Valkey, the Linux Foundation fork, has become the default for new self-hosted and managed deployments, Redis Inc has continued shipping aggressive feature releases against its commercial portfolio, and a handful of alternative engines — KeyDB, Dragonfly, Memcached, and the hyperscaler-native services — occupy specific niches. This post walks through what changed, what to pick, and the production patterns that actually matter.

What the license change actually did#

The relicense was aimed squarely at hyperscaler managed services that resold Redis without contributing upstream. End-users running Redis in their own infrastructure are technically unaffected — SSPL only triggers when you offer Redis itself as a managed service to third parties. Within a week of the announcement, AWS, Google Cloud, Oracle, and Ericsson backed Valkey under the Linux Foundation, with Snap, Alibaba, and Tencent joining shortly after. Valkey 7.2 shipped as a drop-in fork of the last BSD-licensed Redis, and Valkey 8.0 (released late 2024) introduced asynchronous I/O threading that delivered measurable throughput gains over Redis 7.x on the same hardware. By 2026, AWS ElastiCache, GCP MemoryStore, and Oracle Cloud all default to Valkey for new clusters, and most major Linux distributions ship Valkey as the redis-server package.

Redis 8 and the commercial offering#

Redis Inc, meanwhile, has not stood still. Redis 8 (released in mid-2025) integrated the previously-separate Redis Stack modules — RediSearch, RedisJSON, RedisTimeSeries, RedisBloom — into the core distribution rather than keeping them as optional add-ons. The vector-search capabilities have meaningfully improved, with HNSW-backed indexes performing competitively for workloads under roughly 50 million vectors. Redis Enterprise adds active-active geo-distribution via CRDTs, tiered storage to flash, and the operationally important multi-tenancy controls that large deployments need. For shops that already pay for Redis Enterprise, the value proposition has actually strengthened — the gap between open-source Valkey and commercial Redis is wider than it was in 2023.

The forks: KeyDB and Dragonfly#

KeyDB, the multithreaded Redis fork from Snapchat-acquired EQ Alpha, predates the license drama but benefits from it. KeyDB is wire-compatible with Redis, runs threaded by default, and offers active-replication. After the Snap acquisition in 2022, mainline development slowed, and by 2026 most teams that previously chose KeyDB have migrated to Valkey 8, which absorbed many of the same multithreading ideas. Dragonfly, the Go-and-C++ rewrite from former Google engineers, is the more interesting alternative — it ships a shared-nothing architecture, claims order-of-magnitude throughput improvements on multi-core hardware for specific workloads, and supports both Redis and Memcached wire protocols. Dragonfly Cloud now offers a managed service. The catch is feature parity: scripting, modules, and some replication edge cases still differ from Redis behavior, so adoption is concentrated in cache-heavy workloads where the throughput math justifies the migration.

When Redis is the wrong answer#

A surprising amount of Redis deployment is a tooling-default rather than a workload-driven choice. Three counter-recommendations come up often:

Use Postgres instead when the use case is durable application state with relational queries. Postgres with UNLOGGED tables, LISTEN/NOTIFY, and a well-tuned connection pool covers a wider range of “we just need fast reads” use cases than most teams realize, and removes an entire system from the production diagram.

Use Memcached instead when the use case is pure ephemeral cache with no persistence, no pub/sub, and no data structures beyond strings. Memcached’s operational simplicity and predictable memory behavior remain unbeaten for that narrow case.

Use a real queue instead when the use case is reliable job processing. Redis Streams and BullMQ work, but for production at scale, SQS, RabbitMQ, NATS JetStream, or Kafka are the right primitives — and at-least-once semantics with proper visibility timeouts matter more than raw latency.

Production patterns that actually matter#

A few patterns recur across production Redis/Valkey deployments worth naming explicitly. First, set sensible maxmemory and maxmemory-policy — allkeys-lru for pure cache, volatile-lru when mixing cache and durable state. Running without an eviction policy and discovering OOM in production is a regular incident pattern. Second, avoid KEYS * in any code path — use SCAN with appropriate cursor handling. Third, pipeline aggressively — round-trip latency dominates Redis performance, and MGET, MSET, and explicit pipelining typically deliver 10x or better throughput improvements over individual calls. Fourth, use Redis Cluster only when you need it — a single primary with replicas covers a remarkable amount of production load, and cluster operations add real complexity around multi-key commands and Lua scripts. Fifth, monitor INFO replication and INFO persistence — replication lag and AOF rewrite stalls are the two failure modes that surprise teams.

Where pdpspectra fits#

Our data engineering practice deploys Valkey, Redis, and the alternatives across diverse client contexts — sizing clusters, picking the right engine for the workload, and migrating off Redis Inc commercial licensing when the math works. We also help teams realize they should be on Postgres instead.

Related reading: the vector search pgvector post, the modern data stack post, and the database Postgres modern post.

---

Key-value choice depends on workload, not defaults. Talk to our team about your data platform.