💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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.

|---------|---------|-------------|-------|----------|

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

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).

|---------|-----------|-------------|---------------|------------|

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

_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

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

- Redis — https://redis.io/

- Redis 8 Release Notes — https://redis.io/blog/redis-8-ga/

- Redis License FAQ — https://redis.io/legal/licenses/

- Valkey — https://valkey.io/

- Valkey GitHub — https://github.com/valkey-io/valkey

- Linux Foundation Valkey announcement — https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

- KeyDB — https://docs.keydb.dev/

- KeyDB GitHub — https://github.com/Snapchat/KeyDB

- Dragonfly — https://www.dragonflydb.io/

- Dragonfly GitHub — https://github.com/dragonflydb/dragonfly

- Memcached — https://memcached.org/

- Microsoft Garnet — https://microsoft.github.io/garnet/

- Garnet GitHub — https://github.com/microsoft/garnet

- Apache Ignite — https://ignite.apache.org/

- Hazelcast — https://hazelcast.com/

- Infinispan — https://infinispan.org/

- Aerospike — https://aerospike.com/

- Tarantool — https://www.tarantool.io/

- Skytable — https://skytable.io/

- Speedb — https://www.speedb.io/

- AWS Elasticache — https://aws.amazon.com/elasticache/

- AWS Elasticache for Valkey — https://aws.amazon.com/elasticache/valkey/

- AWS MemoryDB — https://aws.amazon.com/memorydb/

- GCP Memorystore — https://cloud.google.com/memorystore

- Caffeine — https://github.com/ben-manes/caffeine

- lru-cache (Node) — https://github.com/isaacs/node-lru-cache

- node-cache — https://github.com/node-cache/node-cache

- cachetools (Python) — https://github.com/tkem/cachetools

- ristretto (Go) — https://github.com/hypermodeinc/ristretto

- bigcache (Go) — https://github.com/allegro/bigcache

- groupcache (Go) — https://github.com/golang/groupcache

- XFetch algorithm (Probabilistic early expiration) — https://www.vldb.org/pvldb/vol8/p886-vattani.pdf

- RedisJSON — https://github.com/RedisJSON/RedisJSON

- RediSearch — https://github.com/RediSearch/RediSearch

- RedisGraph EOL — https://redis.io/blog/redisgraph-eol/

- RedisTimeSeries — https://github.com/RedisTimeSeries/RedisTimeSeries

- RedisBloom — https://github.com/RedisBloom/RedisBloom

- Speedb vs RocksDB — https://www.speedb.io/blog

- Memgraph (RedisGraph alternative) — https://memgraph.com/

- Picodata (Tarantool fork) — https://picodata.io/