Redis, Valkey, and DragonflyDB: A Modern Guide to In-Memory Databases

Redis: the industry standard

For more than a decade, Redis has been the de facto standard in in-memory databases. It powers everything from small side projects to high-traffic platforms.

Even though its core data processing engine remains single-threaded to keep operations simple and atomic, recent versions introduced background and I/O threads to offload blocking work.

• Current state: Redis 8.0 now ships with what used to be "Redis Stack" built in:
  • JSON support
  • time series
  • vector search (Vector Sets)
• Licensing: it now uses a triple license model (RSALv2, SSPLv1, or AGPLv3). This means Redis is no longer OSI-approved open source, and you must carefully review usage in commercial products or managed services.

Redis is still an excellent choice when you need:

• a very mature ecosystem, with clients for essentially every language;
• official enterprise support;
• and a broad set of advanced modules (AI, search, JSON, etc.).

Valkey: community successor and truly open source

Valkey was created as a fork of the last BSD-licensed Redis version (7.2.4). It is backed by the Linux Foundation and supported by companies like AWS and Google.

Its goal is clear: provide a fully open Redis-compatible engine, keeping command and protocol compatibility while improving internal data structures.

• Real open source: it stays under a BSD-style license, aligned with OSI open source.
• Key memory innovation: it redesigned its internal hash table to be more CPU cache-friendly, reducing memory usage by around 20 bytes per key-value pair.
• Valkey 9.0: introduced Atomic Slot Migration, which allows cluster rebalancing up to 9x faster with no client-visible errors.

Valkey is particularly attractive when:

• you are coming from Redis and want near drop-in compatibility;
• your organization requires 100% open source software;
• and you want to optimize cloud costs via reduced memory usage.

DragonflyDB: built for the cloud era

DragonflyDB is not a Redis fork. It is a new engine built from the ground up to fully leverage modern multi-core hardware.

• Architecture: it uses a shared-nothing design, where each thread owns its own shard of data. This removes global locks and bottlenecks, enabling aggressive vertical scaling on a single machine.
• Memory efficiency: its "Dashtable" structure can save between 30% and 60% of memory compared to traditional Redis, depending on your key patterns.
• Performance: in many scenarios it reports being up to 25x faster than a classic Redis deployment, especially for heavy read/write workloads.
• License: it uses a BSL (Business Source License); it is free to use in many scenarios, but not OSI-approved and comes with restrictions for competing services.

DragonflyDB shines when:

• you manage terabytes of in-memory data;
• you need millions of operations per second on a single node;
• you want to reduce the number of instances required to handle your peak load.

Practical comparison

Spring Boot integration

The best part is that all three engines speak the Redis protocol, so from Spring Boot the integration looks almost identical.

In your pom.xml you only need the standard dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

And in application.properties (or application.yml) you simply point to the right host:

# Works the same for Redis, Valkey, and DragonflyDB
spring.data.redis.host=localhost
spring.data.redis.port=6379

A simple cache service looks exactly the same for the three engines:

@Service
public class CacheService {

    @Autowired
    private StringRedisTemplate redisTemplate;

    public void saveData(String key, String value) {
        // Atomic operation in Redis, Valkey, and DragonflyDB
        redisTemplate.opsForValue().set(key, value);
    }
}

As long as your client uses the Redis protocol, switching from Redis to Valkey or DragonflyDB is often a matter of changing the URL and tuning deployment parameters (memory, CPU, persistence, etc.).

How to choose for your project

A practical way to decide is to think along these axes:

• Licensing and company policy:
  • If your organization requires OSI-approved open source, Valkey is usually the natural choice.
  • If you already have commercial agreements or support with Redis, staying with Redis may be simpler.
  • If you want maximum performance and accept a BSL-style license, DragonflyDB is very compelling.
• Workload pattern:
  • For moderate loads and a stable ecosystem, Redis is still more than enough.
  • For environments where cost per GB in memory is critical, Valkey and DragonflyDB can lower the bill.
  • For extreme loads on a single node, DragonflyDB often becomes the primary candidate.
• Cloud strategy:
  • Check what managed services your cloud provider offers for each engine.
  • Evaluate total cost: instances, support, storage, and network traffic.

A metaphor to understand them

Imagine these databases as restaurants:

• Redis is a fine-dining restaurant with more than 15 years of prestige; it has the most complete menu and everyone knows it, but there is sometimes a line because a single head chef (the main thread) must coordinate the key dishes.
• Valkey is a cooperative created by the original chefs; they use very similar recipes, have redesigned the kitchen for efficiency, and promise the entrance will remain free and open.
• DragonflyDB is an industrial kitchen of the latest generation; it has multiple independent stations working in parallel, designed to feed an entire city from a single building without breaking a sweat.

If you think in terms of budget, number of diners (load), and type of service (support, open source, extreme performance), picking between Redis, Valkey, and DragonflyDB becomes much easier.