The best open source in-memory data stores and Redis alternatives in 2026

★ 77,025CNOASSERTIONupdated Oct 2026

best for most backend workloads that want data structures and search in one server

Most backend stacks already run Redis somewhere, and version 8.0 gives you a real reason beyond inertia: search, JSON, time series, and the probabilistic structures moved into the open-source build, so the multi-model pitch that used to need Redis Enterprise or hand-managed module files now ships by default. Sorted sets, streams, and pub/sub cover real coordination needs without a separate message broker, and the client ecosystem — StackExchange.Redis, Lettuce, go-redis — is as deep as this category gets.

Persistence still asks something of you. RDB snapshots can lose data on a crash, AOF with fsync=always kills throughput, and the hybrid setup most people run in production means tuning both well enough to trust them. Cluster mode adds real operational weight on top, and resharding is not something you do without planning.

If the deciding factor is how much a single server can do, this is still the widest net on this page; Valkey and Dragonfly compete with it on licensing and throughput, not on data model breadth.

Our full take →GitHub ↗

★ 27,480CBSD-3-Clauseupdated Oct 2026

best for teams that want Redis's exact behavior without Redis Inc.'s license terms

Valkey exists because of one event: the license change that pushed Redis away from a fully open license, and the Linux Foundation forked the codebase the moment it happened. The protocol and command set are drop-in compatible, so clients, tooling, and muscle memory carry over unchanged, and governance now sits with LF Projects and backers like AWS and Google rather than a single vendor that can rewrite the terms again.

That compatibility comes with Redis's full C codebase, vendored dependencies like jemalloc included, so the repo is heavy and dependency bumps are a manual job rather than a package update. The fork is young enough that a lot of documentation and third-party tooling still assumes Redis naming and behavior, so edge cases can surprise you, and both RDMA and the CMake build are marked experimental — the Makefile path is still the one to run in production.

Pick this over Redis itself when the license is the deciding factor, and over Dragonfly when you want proven Redis semantics rather than a newer architecture chasing throughput.

Our full take →GitHub ↗

★ 31,811C++NOASSERTIONupdated Oct 2026

best for teams hitting Redis's single-core ceiling who want more throughput per instance

Dragonfly's pitch is architectural, not cosmetic: a shared-nothing, thread-per-core design in place of Redis's single-threaded event loop, built to get more out of one instance instead of adding nodes. Fork-less snapshotting is the detail worth paying attention to — Redis's bgsave can spike memory badly under write load, and Dragonfly's approach sidesteps that directly. Command coverage is broad enough, around 185 commands, that migrating an existing Redis-speaking app is usually low friction, and a built-in HTTP console plus Prometheus metrics on the same port save you wiring up separate observability.

The throughput numbers are all self-reported, benchmarked against instance types the project picked rather than a tuned Redis configuration you'd run yourself, so treat them as a starting point rather than a guarantee for your workload. Cluster mode and replication are newer here and don't carry Redis's decades of hardening, and the license is BSL rather than fully permissive, worth checking against company policy before you commit. The project also clearly wants you on Dragonfly Cloud, which shows in where some of the docs point.

Reach for this when you're CPU- or memory-bound on Redis and want more out of the same box; reach for Valkey instead if license permissiveness matters more than raw throughput.

Our full take →GitHub ↗

★ 14,298CBSD-3-Clauseupdated Sep 2026

best for pure caching workloads with no need for data structures or persistence

Memcached predates this entire category and still runs under a large share of the web, and the codebase shows it: a multithreaded event-based server with extstore for disk-backed LRU tiering, TLS, SASL auth, and now an experimental Lua-scriptable proxy for routing and rate-limiting without extra infrastructure. The test suite reads like a bug-report archive — files named after the issues they fix — a reasonable sign the project closes what it breaks.

What it doesn't do matters as much as what it does: no data structures beyond a flat key-value cache, no persistence, no replication story, so you're choosing this specifically because you don't want Redis's extra surface area, not because you forgot about it. Security issues get handled privately before disclosure, a defensible policy, but it means you won't see details until after a fix ships.

Pick this when the job is strictly caching and you want the longest-running thing that does only that; pick Redis or Valkey the moment you need sorted sets, pub/sub, or any durability.

Our full take →GitHub ↗

★ 6,623JavaNOASSERTIONupdated Oct 2026

best for Java shops running stream processing and a data store in the same process

Hazelcast runs in-memory storage, stream processing, and SQL querying inside the same Java process, aimed less at caching and more at workloads — financial services, telco — where keeping compute next to the data is the whole point. The Jet stream engine's published numbers, 10 million events per second per node under 10ms P99, are backed by real benchmarks rather than marketing copy, and the internal design docs on partition migration, split-brain recovery, and the SQL optimizer are detailed enough to explain how the system behaves under failure.

The dual license is the thing to read closely before adopting it: WAN replication, the HD Memory Store persistence option, and the full management center sit under the Hazelcast Community License, which blocks competing SaaS use and requires a commercial agreement at scale, and you often won't notice you've crossed that line until you're already in production. At 6.5k stars for a project running since 2008, the community is thin next to Redis's, so you're more likely to be debugging Hazelcast internals without much to search against. Configuration is also spread across XML, YAML, and programmatic config with no clear precedence, so expect some trial and error getting a cluster to agree with itself.

This is worth the complexity only if you need stream processing, SQL, and a data store sharing memory and a process; for a cache or key-value store alone, everything else here is simpler.

Our full take →GitHub ↗

★ 3,501GoApache-2.0updated Aug 2026

best for Go services that want a clustered cache without running separate Redis infrastructure

Olric gives Go developers a clustered in-memory store that runs either embedded in your binary or as a standalone server, speaking RESP so any Redis client works against it without modification. Consistent hashing rebalances automatically when nodes join or leave, with no external coordinator like ZooKeeper or etcd required — a real simplification next to something like Hazelcast, which assumes a dedicated cluster. The storage engine packs values into pre-allocated byte slices instead of regular Go heap objects, which keeps GC pauses down at high key counts.

The consistency model is available-over-consistent under partition, and the README says so plainly, but the distributed locking primitive is explicitly labeled approximate and meant for non-critical use, which rules it out for anything resembling real coordination. There's no TLS and authentication is password-only, so you're relying entirely on network isolation for security. The project also renamed itself from buraksezer/olric to olric-data/olric at v0.6, and the warning about it is still prominent in the README, a sign the community and tooling around it are still catching up.

This fits a Go-only shop that wants shared memory across instances without standing up Redis, as long as nothing in the design needs strong locking or runs on an untrusted network.

Our full take →GitHub ↗

★ 4,566GoBSD-3-Clauseupdated Feb 2026

best for Go developers who want Redis semantics backed by SQLite or Postgres with real ACID transactions

Redka takes Redis's data structures — strings, lists, sets, hashes, sorted sets — and rebuilds them on top of SQLite or Postgres, speaking RESP so existing Redis clients connect without changes. The appeal is transactional: you can update a hash and a row in the same Postgres transaction with real ACID guarantees, something no amount of Lua scripting gets you in Redis itself. Running it in-process also makes it a lighter Redis test double than spinning up a Docker container for every test run.

It doesn't chase Redis's performance, and the sorted set benchmarks show why — SQL's ORDER BY with scoring is a different algorithmic problem than a skip list, and it shows under load. Pub/sub, streams, and Lua scripting are all missing, so anything built on those isn't moving over here. The author has put it in maintenance mode with no new features planned, and it's bound to a single Postgres or SQLite instance, so clustering and replication are whatever that backing database already gives you.

Reach for this when you want Redis's command surface with a relational backend underneath, not when you need Redis's throughput or its pub/sub and streaming features.

Our full take →GitHub ↗