Skip to content
Published on

In-memory Caching & KV Stores in 2026 — Redis 8 / Valkey / KeyDB / Dragonfly / Memcached / Garnet (Microsoft) / Speedb Deep Dive

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. The 2026 Caching Map — The Era of the Redis vs Valkey Schism

In 2026 the in-memory cache market is no longer "just Redis." In March 2024 Redis Ltd. abandoned its BSD license for a dual RSALv2 / SSPL stack, which prevented cloud vendors from selling Redis as a managed service. The backlash produced Valkey, a Linux Foundation fork. Eighteen months later, the cache market has split into five lanes.

  • Redis 8 — the surviving Redis Ltd. lineage under RSALv2 / SSPL
  • Valkey — Linux Foundation BSD fork (AWS / GCP / Oracle / Snap / Alibaba backed)
  • Dragonfly — multi-threaded RESP-compatible newcomer (Roman Gershman)
  • KeyDB — Snap-acquired multi-threaded Redis fork
  • Garnet — Microsoft Researchs .NET-based RESP server, announced March 2024

Add Memcached (still simple), the JVM data grids (Apache Ignite, Hazelcast, Infinispan), Aerospike (hybrid memory/SSD), Tarantool (Russia), Skytable (Rust), and the RocksDB fork Speedb — and 2026's choice is less "what to pick" and more "what we can ignore."

This article surveys all those caches and KV stores as of May 2026. From a small team that needs a sidecache to a global multi-region platform, this is the map to find your fit.

2. Redis 8 — Life After the RSALv2/SSPL Relicense

On March 20, 2024, Redis Ltd. announced that starting with Redis 7.4 it would abandon BSD 3-Clause for a dual RSALv2 / SSPLv1 license. In May 2025, after the success of the Valkey fork, Redis 8 added an AGPLv3 option — so non-cloud users could once again call it "open source," but cloud vendors selling Redis as a managed service still need RSALv2 / SSPL / commercial.

Key changes in Redis 8.

  • Stronger multi-threaded I/O — the single-threaded core stays, but network and disk I/O move to thread pools
  • Vector Sets as a first-class type — embedding vectors in the core (lighter than RediSearch HNSW)
  • Streams Consumer Group automatic failover
  • RESP3 cleanups for HyperLogLog, Bitfield, Geo
  • Cluster mode auto-rebalancing improvements
  • RedisJSON, RediSearch, RedisTimeSeries, RedisBloom merged into the core (AGPL option uses separate modules)

The license policy is, at heart, "stop AWS / GCP / Azure from reselling Redis as managed SaaS." Individual developers can still spin it up with Docker freely; reselling it as a public managed service triggers SSPL.

# Redis 8 via Docker (personal / internal use is free)
docker run -d --name redis8 \
  -p 6379:6379 \
  -v redis8-data:/data \
  redis:8

# New Vector Sets type
redis-cli VSET.ADD myset:vectors "doc-1" 0.1 0.2 0.3 0.4
redis-cli VSET.SEARCH myset:vectors VECTOR 0.1 0.2 0.3 0.4 COUNT 10

The biggest operational change for Korean / Japanese shops is Sentinel deprecation. Redis Ltd. has pushed Cluster mode since 7.x, and in 8 Sentinel enters "maintenance only" status. Shops at Kakao and Toss that ran Sentinel-based HA now have Cluster migrations as one of 2026's biggest infra projects.

3. Valkey — Linux Foundation Redis Fork (March 2024)

Valkey is a Linux Foundation fork that launched eight days after the Redis relicense. Major backers include AWS, Google Cloud, Oracle, Snap, Alibaba, Verizon, and Ericsson — effectively a hyperscaler-coalition Redis backup.

Valkey core promises.

  • BSD 3-Clause license — permanent, immutable
  • Forked from Redis 7.2.4 (RESP2 / RESP3 compatible)
  • Governance under the LF Technical Steering Committee (TSC)
  • Core contributors are engineers from AWS, Google, Oracle

Valkey 8.0 shipped in April 2025; as of May 2026, Valkey 8.1 is stable. Differentiators.

  • Multi-threaded I/O by default — adopted faster than Redis 8
  • Per-key locking (key-level lock) for better hot-key distribution
  • RDMA-based cluster communication option
  • Improved async replication reliability
  • VKEYS — a Valkey-native vector search structure (separate from Redis Vector Sets)

AWS launched Elasticache for Valkey in late 2024 with a "33% cheaper than Elasticache for Redis" headline. GCP MemoryStore added Valkey in mid-2025.

# Valkey via Docker
docker run -d --name valkey \
  -p 6379:6379 \
  -v valkey-data:/data \
  valkey/valkey:8.1

# redis-cli just works (RESP compatible)
redis-cli -h localhost SET key1 "Valkey value"
redis-cli -h localhost GET key1
# returns "Valkey value"

Existing Redis clients (redis-py, ioredis, lettuce, jedis, go-redis) connect to Valkey unchanged. Low migration cost is Valkeys biggest strength.

4. KeyDB — Snap Acquisition

KeyDB is a multi-threaded Redis fork made by EQ Alpha Technology in 2019. The core supports the same Redis data structures and commands, but the event loop runs across multiple cores to use more CPU on a single host.

In January 2022, Snap (Snapchats parent) acquired EQ Alpha and absorbed KeyDB into its internal cache infrastructure. There was a stretch where KeyDB looked dead, but in 2024 Snap contributed parts of the KeyDB codebase upstream to Valkey, reactivating the project.

KeyDB differentiators.

  • Multi-threading — one instance uses many cores
  • Active-Active replication — bidirectional sync (multi-master)
  • FLASH mode — RocksDB backend offloads cold data to SSD
  • Subkey expiration — per-field TTL inside a Hash
# KeyDB via Docker
docker run -d --name keydb \
  -p 6379:6379 \
  -e KEYDB_THREADS=4 \
  eqalpha/keydb

# Active-Active bidirectional sync (conceptual)
keydb-cli REPLICAOF 192.168.1.10 6379
keydb-cli REPLICAOF 192.168.1.11 6379
# Each node becomes a replica of the other → bidirectional sync

As of 2026 KeyDB sits in an awkward spot. Single-host multi-threading is faster on Dragonfly, Active-Active is more stable on Redis Enterprise CRDT, and Snaps active marketing has gone quiet. Still, if you want "multi-threaded Redis with no license drama," KeyDB 7.x remains a reasonable pick.

5. Dragonfly — The Multi-Threaded Competitor

Dragonfly is a RESP-compatible in-memory datastore announced by Roman Gershman (formerly Google) in May 2022. Its "25x faster than Redis" benchmarks made it famous, and in 2026 it is the fastest-growing newcomer in the cache space.

Dragonflys signature is a true multi-threaded architecture. Redis runs a single-threaded event loop; KeyDB and Valkey use "multi-threaded I/O + single-threaded core"; Dragonfly is shard-per-thread at the core. On an 8-core machine, 8 independent shards run in one process.

Technical differentiators.

  • Shard-per-thread — one core owns all keys for one shard
  • Threadsafe IO — async I/O via io_uring
  • Memory-efficient — 30–50% lower memory vs Redis (LRU plus compression)
  • Snapshot — fork-less BGSAVE (avoids the Redis fork-bomb)
  • Built-in BulSearch and vector search
# Dragonfly via Docker
docker run -d --name dragonfly \
  --ulimit memlock=-1 \
  -p 6379:6379 \
  docker.dragonflydb.io/dragonflydb/dragonfly

# Same clients as Redis
redis-cli SET large_key "value"
redis-cli MEMORY USAGE large_key
# Dragonfly reports lower usage than Redis

The Dragonfly license is BSL 1.1 (Business Source License). It auto-converts to Apache 2.0 after 4 years, but until then you cannot run it as a "Dragonfly competing SaaS." Individual developers and internal operators use it for free.

Dragonfly Inc. sells Dragonfly Cloud (managed) and Dragonfly Swarm (multi-node clusters) commercially and raised a Series B in 2024–2025.

6. Memcached — Still Simple

Memcached was created by Brad Fitzpatrick in 2003 for LiveJournal — the original distributed in-memory cache. Twenty-three years later in 2026, it is still alive and still first-choice in some spots.

Why Memcached survives — simplicity.

  • Key/value only (no data structures — Hash/List/Set all client-serialized)
  • LRU eviction automatic
  • Multi-threaded by default (before Redis)
  • No persistence — data lost on restart (intentional design)
  • Slab allocator avoids fragmentation
# Memcached via Docker (pure cache)
docker run -d --name memcached \
  -p 11211:11211 \
  memcached:1.6 \
  -m 512 \
  -t 4

# Talk to it with telnet (plain text protocol)
telnet localhost 11211
> set hello 0 60 5
> world
> STORED
> get hello
> VALUE hello 0 5
> world
> END

Facebook, Twitter (legacy), and Pinterest use Memcached as a pure cache. When you do not need Redis data structures, persistence, or transactions, Memcached is lighter and faster.

In Korea, parts of Naver Searchs cache layer (search keyword → result IDs) still run on Memcached. In Japan, LINE Messenger backend pieces and Yahoo Japan search use Memcached.

7. Garnet (Microsoft, March 2024) — .NET-Based RESP Server

Garnet is a .NET-based RESP-compatible in-memory datastore that Microsoft Research surprise-released on March 18, 2024. The shocker was the benchmark claim — "100–900% higher single-node throughput than Redis."

Garnet highlights.

  • Built on .NET 8 / 9 — written in C# (runs on a garbage collector)
  • RESP2 / RESP3 compatible — Redis clients connect unchanged
  • Tsavorite KV store — Microsofts own KV engine (successor to FASTER)
  • Supports Pub/Sub, Streams, Cluster mode
  • Multi-threaded + lock-free data structures
# Garnet via Docker
docker run -d --name garnet \
  -p 6379:6379 \
  ghcr.io/microsoft/garnet

# redis-cli just works
redis-cli PING
# returns PONG
redis-cli SET hello "Garnet"
redis-cli GET hello
# returns "Garnet"

Garnets surprising claim is that a .NET cache on a GC can beat C-written Redis. Years of Tsavorite KV (formerly FASTER) tuning produce lock-free queue and hash structures that win big on multi-core hardware.

License is MIT — about as permissive as it gets. Cloud vendors are free to resell Garnet as a managed service. Azure released "Garnet for Azure Cache" in preview in late 2025.

The downside is the .NET dependency. Operators unfamiliar with .NET runtime tuning struggle with GC and memory profiling. So the common framing is "Garnet is best at .NET shops."

8. Apache Ignite / Hazelcast / Infinispan — The JVM Camp

The JVM world has a separate "in-memory data grid" category. Not a simple KV like Redis but a unified platform that also runs SQL queries, transactions, compute, and even ML inference.

Apache Ignite

Apache Foundations in-memory data grid plus compute platform. SQL ANSI-99 compliant, distributed transactions, ML module, and Native Persistence to disk.

// Access an Ignite cluster from Java
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.cache("orders");
cache.put("order:1", new Order(...));

// SQL works the same way
SqlFieldsQuery query = new SqlFieldsQuery(
  "SELECT id, amount FROM Order WHERE customerId = ? LIMIT 100");
List rows = cache.query(query.setArgs(42)).getAll();

In 2026 GridGains commercial Ignite distribution is the main channel. Heavily used in US aviation, finance, and healthcare — regulated industries that want in-memory SQL grids.

Hazelcast

The flagship commercial in-memory data grid. Clients in Java / Node / Python / C++, Jet for stream processing, Hazelcast IMDG / Hazelcast Platform full stack.

  • Distributed Map / Queue / Set / Lock / Semaphore
  • Compute Grid — distributed task execution
  • Jet — stream processing (similar to Apache Flink)
  • Hazelcast Management Center — cluster monitoring and admin

Infinispan (Red Hat)

Red Hats open-source in-memory data grid. Strong integration with JBoss / Quarkus / WildFly, and the canonical JCache (JSR 107) implementation.

JVM tools are not just "simple caches" — they are in-memory data platforms. Their core customers are the big enterprises on the JVM (banks, insurance, telecom, government).

9. Aerospike — Hybrid Memory/Disk

Aerospike is a distributed KV store famous for a hybrid model — "indexes in RAM, values on SSD." Instead of loading all data into RAM like Redis, it leans on NVMe SSDs random access performance to handle very large datasets.

Differentiators.

  • Hybrid Memory Architecture — RAM indexes only, values read directly from SSD
  • Strong consistency option (Aerospike SC)
  • Cross-datacenter Replication (XDR)
  • Aerospike Vector Search — added 2024
  • TPS — validated past 1 million TPS per cluster
# Aerospike via Docker
docker run -d --name aerospike \
  -p 3000-3002:3000-3002 \
  aerospike/aerospike-server

# Python client
python3 << EOF
import aerospike
client = aerospike.client({'hosts': [('localhost', 3000)]}).connect()
key = ('test', 'demo', 'foo')
client.put(key, {'name': 'Alice', 'age': 30})
(key, meta, bins) = client.get(key)
print(bins)
EOF

Aerospike customers include AdTech (AppLovin, Criteo, Trade Desk), finance (PayPal, Wells Fargo), and games (King, Riot Games). It shines at "10 billion keys per cluster, 1 ms response."

Aerospike 8.0 is the May 2026 stable, positioned as a multi-model database with vector search, graph, and time series integrated.

10. Tarantool — Russian In-Memory DB

Tarantool was created in 2010 by Russias Mail.ru (now VK). Not just a cache but a full-stack DB with Lua stored procedures, SQL, persistence, and clustering integrated.

  • In-memory + WAL — held in memory, persisted to disk
  • Lua stored procedures — embed backend business logic
  • SQL (Tarantool SQL) plus NoSQL (tuples)
  • Vinyl engine — LSM-tree disk engine for big workloads
  • Cluster — Cartridge framework for cluster ops
-- Create a Space and insert data in Tarantool (Lua)
box.cfg{ listen = 3301 }
s = box.schema.space.create('users', {
  format = { {name='id', type='unsigned'}, {name='name', type='string'} }
})
s:create_index('primary', { parts = {'id'} })

s:insert{1, 'Alice'}
s:insert{2, 'Bob'}
print(s:get{1})
-- → [1, 'Alice']

Russia and Eastern Europe use Tarantool as an active Redis alternative. In Japan, NTT famously adopted Tarantool as the session store for its 5G Core — telecoms specific reliability requirements made it preferable to Redis. Korea barely uses it, but the global telecom and gaming markets have a deep user base.

After 2022, international sanctions split the core team — the project forked into "Picodata," and both branches are evolving.

11. AWS Elasticache vs MemoryDB vs Valkey Options

AWSs in-memory cache / KV story has three lanes in 2026. Pick the right one using this table.

ServiceLicensePersistencePriceUse case
Elasticache for RedisRSALv2/SSPLOptional (backup)StandardMaximum Redis compatibility
Elasticache for ValkeyBSDOptional (backup)33% cheaper than RedisNew workloads, license-free
Elasticache for MemcachedBSDNoneCheapestPure cache
MemoryDB for RedisRSALv2/SSPLMandatory (Multi-AZ WAL)Most expensiveUse as primary DB
MemoryDB for ValkeyBSDMandatory (Multi-AZ WAL)Slightly cheaper than MemoryDB for RedisPrimary DB, license-free

MemoryDB is "a persistent KV DB with a Redis-compatible interface." Multi-AZ WAL guarantees zero data loss, but costs 3 to 4 times more than Elasticache. Elasticache is "a cache in front of a DB"; MemoryDB is "the DB itself."

# Create an Elasticache for Valkey cluster via AWS CLI
aws elasticache create-cache-cluster \
  --cache-cluster-id my-valkey \
  --engine valkey \
  --engine-version 8.1 \
  --cache-node-type cache.t4g.small \
  --num-cache-nodes 1

# MemoryDB for Valkey cluster (persistent + Multi-AZ)
aws memorydb create-cluster \
  --cluster-name my-memorydb \
  --engine valkey \
  --node-type db.t4g.small \
  --num-shards 1 \
  --num-replicas-per-shard 2

As of May 2026, AWSs recommendation is — "new projects start on Valkey; Elasticache for Valkey if you only need Redis wire compatibility, MemoryDB for Valkey if you need Multi-AZ persistence." The license shake-up is now baked into the price list.

12. Skytable / Speedb — Rust and a RocksDB Fork

Two "next-gen contenders" worth attention in 2026.

Skytable

Skytable is a Rust-based NoSQL database under BSL. Supports RESP and Skyhash protocols, the BlueQL query language (SQL-like), and a hybrid row + key-value model.

# Skytable via Docker
docker run -d --name skytable -p 2003:2003 skytable/sky:latest

# Skytable CLI (skysh)
skysh -p 2003
> create model app.users(username: string, password: string)
> insert into app.users('alice', 'secret123')
> select * from app.users where username = 'alice'

Skytables wins are Rust safety, multi-threading, and a single binary. Small teams looking for "a Redis alternative with a bit of SQL-ish querying" pick it incrementally.

Speedb

Speedb is a fork of Metas RocksDB built to be "a faster RocksDB." It keeps the RocksDB API but rewrites compaction, Bloom filters, and memory management to deliver 2–5x throughput on the same workload.

  • Drop-in API — switch libraries with no code change
  • Apache 2.0 license
  • ~40% lower memory usage after compaction
// Use Speedb from C++ — same interface as RocksDB
#include <rocksdb/db.h>

rocksdb::Options options;
options.create_if_missing = true;
rocksdb::DB* db;
rocksdb::DB::Open(options, "/tmp/speedb_test", &db);

db->Put(rocksdb::WriteOptions(), "hello", "world");
std::string value;
db->Get(rocksdb::ReadOptions(), "hello", &value);
// returns "world"

Speedb is an embedded library, not a standalone KV server. So it positions itself less as a Redis alternative and more as a "performance upgrade for every RocksDB-based system" (Kafka, MyRocks, TiKV).

13. In-Process Libraries — node-cache / lru-cache / cachetools / Caffeine

Beyond distributed cache servers, there is the in-process cache inside your application — "a 5-minute TTL on an internal Map" rather than "Redis in front of the DB." This is more common than people admit.

Node.js — lru-cache, node-cache, keyv

  • lru-cache (by Isaac Schlueter, npm author) — the de-facto standard. LRU + TTL + max size
  • node-cache — simple TTL only (no LRU)
  • keyv — multi-adapter abstraction (Redis, SQLite, Memory)
// lru-cache usage
import { LRUCache } from 'lru-cache'

const cache = new LRUCache({
  max: 500,
  ttl: 1000 * 60 * 5, // 5 minutes
  updateAgeOnGet: true,
})

cache.set('user:42', { name: 'Alice' })
console.log(cache.get('user:42'))

Python — cachetools, functools.lru_cache, diskcache

  • functools.lru_cache — standard library, decorator based
  • cachetools — LRU, LFU, TTL, RR (random replacement) policies
  • diskcache — disk-backed cache (single-process embedded)
# cachetools usage
from cachetools import TTLCache, cached

cache = TTLCache(maxsize=100, ttl=300)  # 5 minutes

@cached(cache)
def expensive_query(user_id):
    return db.query("SELECT * FROM users WHERE id = ?", user_id)

Java — Caffeine, Guava Cache, EHCache

  • Caffeine (Ben Manes) — the de-facto standard. W-TinyLFU policy, async loader, blazing fast
  • Guava Cache — old standard. Replace with Caffeine in modern code
  • EHCache — Terracotta / Ehcache 3, JCache implementation
// Caffeine usage
LoadingCache cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(5))
    .recordStats()
    .build(key -> loadFromDb(key));

User user = cache.get("user-42");

Go — bigcache, ristretto, groupcache

  • ristretto (Dgraph) — concurrency-optimized W-TinyLFU
  • bigcache (Allegro) — GC-optimized (byte slice, no pointers)
  • groupcache (Brad Fitzpatrick, the Memcached author) — built-in singleflight

In-process caches are vastly faster than distributed caches (about 1 ns vs 1 ms). So "L1 = in-process library, L2 = Redis/Valkey" is the canonical multi-tier pattern.

14. Distributed Cache Patterns — cache-aside / read-through / write-through / write-back / write-around

When using a distributed cache, the sync strategy between cache and backend DB controls correctness, performance, and consistency trade-offs.

Cache-aside (Lazy loading)

The most common pattern. The application talks to both cache and DB directly.

def get_user(user_id):
    # 1. Look up cache
    user = cache.get(f"user:{user_id}")
    if user:
        return user

    # 2. Cache miss → query DB
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    # 3. Update cache
    cache.set(f"user:{user_id}", user, ttl=300)
    return user

Pros — simple and survives cache outages (DB fallback). Con — slow responses on cache miss.

Read-through

The cache server queries the DB itself. The application only sees the cache.

# Cache library takes a loader
@cached_loader(loader=lambda k: db.query(f"SELECT * FROM users WHERE id = '{k}'"))
def get_user(user_id):
    return cache.get(f"user:{user_id}")

Caffeines LoadingCache and Hazelcasts MapStore use this pattern.

Write-through

Writes go cache → DB synchronously. Consistency is preserved, but writes get slow.

Write-back (Write-behind)

Writes update only the cache, with DB updated asynchronously later. Very fast, but cache outage risks data loss.

Write-around

Writes go to the DB only; cache is filled lazily on reads. Fits workloads with lots of write-once-rarely-read data (logs, events).

PatternRead perfWrite perfConsistencyComplexity
Cache-asideSlow on missFast (cache untouched)Medium (race conditions possible)Low
Read-throughAuto on missFastMediumMedium
Write-throughFastSlow (2 writes)StrongMedium
Write-backFastVery fastWeak (loss risk)High
Write-aroundSlow on missFastStrongLow

Most web services start with cache-aside. As write patterns mature, teams move to write-around or read-through; transactional systems with strict consistency move to write-through.

15. Hot Key + Cache Stampede — Avoiding It with singleflight + dogpile

Two of the most common production incidents in distributed cache ops are hot keys and cache stampedes.

Hot key problem

A specific key (e.g. "homepage top 10 products," "todays exchange rate") soaks up all traffic on a single shard. Even in Redis Cluster mode, a single key is pinned to a single shard — that shards CPU pegs at 100%.

Mitigations.

  • Key sharding — split into "top10:1", "top10:2" and let the client pick randomly
  • Client-side caching — Redis 6.0+ client-side caching, or an lru-cache L1
  • Read replicas — Redis Cluster + replica reads

Cache stampede (Thundering herd / Dogpile)

The moment a key expires, every request hits the DB at once. 1000 RPS of traffic instantly becomes 1000 DB queries.

Patterns to defend.

# singleflight pattern — borrowed from Go groupcache
import threading

_locks = {}
_lock_lock = threading.Lock()

def get_or_load(key, loader):
    cached = cache.get(key)
    if cached:
        return cached

    # Only one loader runs per key
    with _lock_lock:
        if key not in _locks:
            _locks[key] = threading.Lock()
        key_lock = _locks[key]

    with key_lock:
        # Re-check cache (an earlier request may have filled it)
        cached = cache.get(key)
        if cached:
            return cached

        # Actually run the loader
        value = loader()
        cache.set(key, value, ttl=300)
        return value

Other patterns.

  • Probabilistic early expiration — refresh only a fraction of requests just before expiry (XFetch algorithm)
  • Stale-while-revalidate — return the stale value immediately, refresh in the background
  • Refresh-ahead — auto-refresh in the background before expiry (Caffeine refreshAfterWrite)
# XFetch — pairs nicely with Redis 7+ CLIENT NO-EVICT
import random, math, time

def xfetch(key, ttl, beta=1.0):
    val, delta, expiry = cache.get_with_meta(key)
    if val is None:
        # Cache miss → always refresh
        return refresh(key)

    if time.time() - delta * beta * math.log(random.random()) >= expiry:
        # Pre-expiry, refresh only a fraction of callers
        return refresh(key)

    return val

Real-world ops at Toss and Kakao most often combine "singleflight + Refresh-ahead" — one loader per key, with the background refresh kicking in before expiry.

16. The Redis Module Diaspora — RedisJSON, RediSearch, RedisGraph (sunset), RedisTimeSeries, RedisBloom

The Redis Ltd. relicense shook the module ecosystem too. As of 2026, here is the state of the major modules.

  • RedisJSON — merged into the Redis 8 core (AGPL / RSAL / SSPL license)
  • RediSearch — merged into the Redis 8 core, vector search and full-text search
  • RedisGraph — sunset announced July 2023, EOL in 2025
  • RedisTimeSeries — merged into the Redis 8 core
  • RedisBloom — merged into the Redis 8 core (Bloom, Cuckoo, Count-Min Sketch)

The Valkey camp is building its own alternatives.

  • VKEYS Vector Search — Valkeys native vector search (separate from Redis Vector Sets)
  • Valkey JSON — under development as a module called Cocoa
  • Valkey Search — RediSearch replacement under development
  • Valkey Bloom — separate Bloom Filter module

RedisGraph EOL hit graph DB users hard. Alternatives include Memgraph (in-memory graph DB), Neo4j, and ArangoDB.

# Use JSON in the Redis 8 core (no separate module loading)
redis-cli JSON.SET user:1 $ '{"name":"Alice","age":30}'
redis-cli JSON.GET user:1 $.name
# returns "Alice"

# Vector Search (RediSearch integration)
redis-cli FT.CREATE products ON HASH PREFIX 1 product: \
  SCHEMA name TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

Module integration vs fragmentation is, ultimately, a political question — "whose Redis becomes the standard?" Larger orgs watch Valkey module progress and plan slow migrations.

17. Korea / Japan — Kakao, Toss, Mercari, NTT

A quick snapshot of regional ops.

Korea — Kakao, Toss, Naver, Coupang

  • Kakao — Redis Cluster + Sentinel base, Valkey migration started after the 2024 relicense. KakaoTalk message queues, friends list, chat room cache
  • Toss — Redis 7.x, self-operated, MSA architecture with one Redis cluster per service. Insiders say "if Redis dies, Toss stops"
  • Naver — Memcached + Redis mix. Search result caching is still Memcached; recommendations on Redis Cluster
  • Coupang — heavy use of AWS Elasticache for Redis. Valkey migrations underway after the license shock
  • LINE (LY Corp) — Redis Sentinel + custom solutions, independent clusters per global data center

Japan — Mercari, NTT, Yahoo Japan, LINE

  • Mercari — GCP MemoryStore for Redis, product search cache and user sessions. Started Valkey PoCs in 2025
  • NTT — famously chose Tarantool as the session store for its 5G Core. Telecoms reliability requirements pushed it past Redis
  • Yahoo Japan — Memcached + custom KV. Search and ad caches on Memcached; user data on its own distributed KV
  • LINE — heavy Redis Cluster use, with separate ops in Japan LINE and Taiwan LINE
  • Cygames — Redis Cluster + Aerospike mix, used for live mobile game leaderboards and inventory

The common thread between Korea and Japan is "evaluating Valkey migration after the Redis relicense." The difference is Japan being more conservative — "evaluating quietly for a long time" — while Korea pushes "PoC fast → ship fast."

18. Who Should Pick What — Simple / Complex Structures / Distributed / Enterprise

Finally, recommendations.

Simple cache (TTL only)

→ Memcached. One Docker line for a single node, client-side sharding for a cluster. If you are sure you do not need Redis data structures, Memcached is lighter.

Complex data structures (Hash / List / Set / Sorted Set / Stream)

→ Redis 8 (if license is OK) or Valkey 8.1 (if open source is the priority). The de-facto standard with the richest clients, tools, and docs.

Maximum single-node multi-threaded throughput

→ Dragonfly. Max throughput and minimum memory on a single machine. Drop-in Redis replacement.

.NET / Azure environment

→ Garnet. MIT license + friendly C# ops. On Azure, lean on the Cache for Garnet preview.

SQL + in-memory grid + transactions

→ Apache Ignite (open source) or Hazelcast (commercial support). Big enterprise workloads in finance, telecom, healthcare.

Datasets larger than RAM (Hybrid)

→ Aerospike. RAM indexes + SSD values means 10 billion keys is fine.

Embedded Lua business logic + in-memory DB

→ Tarantool. Especially good for telecom and gaming.

AWS managed

→ For new workloads, Elasticache for Valkey or MemoryDB for Valkey. Keep Elasticache for Redis only if existing Redis compatibility is mandatory.

Rust / safety priority

→ Skytable (or Dragonfly, which is C++). Single binary, memory-safe.

Embedded RocksDB-based KV

→ Speedb. Performance upgrade without code change.

In-process cache (application library)

→ Java — Caffeine. Node — lru-cache. Python — cachetools. Go — ristretto.

Pattern guide

  • Read-heavy + weak consistency → Cache-aside + lru-cache (L1) + Redis (L2)
  • Write-heavy + strong consistency → Write-through + Caffeine + MemoryDB
  • Massive data → Aerospike or Ignite Native Persistence
  • Global multi-region → Redis Enterprise CRDT or KeyDB Active-Active
  • Simple LRU → Memcached + client lru-cache

The 2026 caching decision is no longer "use Redis." It is "which Redis version / fork, with which pattern, paired with which library?" The license fallout grew the markets diversity — and now we have to choose carefully.

19. References

Discuss on Twitter • View on GitHub