Redis vs KeyDB vs Dragonfly: что брать под кэш и очереди

22 мая 2026 г. 10K

Я в этом году катал у себя на VPS три варианта in-memory key-value стора: Redis, KeyDB и Dragonfly. Цель была не выбрать «один на все случаи», а понять, где какой работает лучше: под кэш, под BullMQ-очереди, под rate limit, под pub/sub. Делюсь наблюдениями.

Краткое представление участников

Redis — оригинал. Однопоточный (event loop), огромная экосистема, плагины (RedisGraph, RediSearch, RedisJSON). Версия 7 уже умеет ACL, streams, RDB+AOF.
KeyDB — форк Redis с многопоточностью. API совместим с Redis 6/7. Существует со времён, когда у Redis ещё не было multi-thread I/O.
Dragonfly — независимая реализация на C++ с другой архитектурой (shared-nothing, multi-thread). Совместим с Redis по протоколу и большинством команд. Памяти ест меньше за счёт компактных структур.

Что мерила

На VPS 4 vCPU / 8 GB RAM, Ubuntu 24.04. Все три — последние стабильные версии (Redis 7.4, KeyDB 6.3, Dragonfly 1.20). Тесты:

SET/GET с маленькими значениями (пайплайн 100, ключи на 64 байта, значения 256 байт). Через redis-benchmark. Грубо — пропускная способность.
BullMQ-сценарий: 50 воркеров, 100 jobs/сек, по 1 KB payload. Меряем медиану времени enqueue → done.
Память: на 1 миллион ключей с сериализованным JSON (~600 байт каждое значение).
Стабильность под рестартом сервиса и при OOM-killer.

Производительность на простых SET/GET

Redis: ~140k ops/sec на одном инстансе.
KeyDB: ~330k ops/sec при server-threads 4.
Dragonfly: ~600k ops/sec по умолчанию, на 4 потоках.

Цифры приблизительные, зависят от размеров и пайплайна. Главное наблюдение — на одном CPU все три плюс-минус одинаковы. Разница появляется, когда становится больше одного ядра. Redis традиционно это решает с помощью io_threads, но io_threads ускоряет только I/O, а команды всё равно выполняются однопоточно.

BullMQ-сценарий

Это типичная очередь Node-приложения. Я стартовала те же 50 воркеров, тот же payload, но переключала backend.

Redis: медиана enqueue→done 18 мс, p95 45 мс.
KeyDB: 16 мс / 40 мс.
Dragonfly: не подошёл.

BullMQ опирается на Redis Streams и Lua-скрипты. Dragonfly streams и Lua поддерживает не полностью, и пара команд BullMQ выдаёт ошибки совместимости. На последних версиях (1.20+) поддержка значительно улучшилась, но я бы перепроверила свой стек прежде, чем ставить Dragonfly под BullMQ. У меня BullMQ остался на Redis/KeyDB.

Память

1 миллион ключей JSON ~600 байт:

Redis: ~720 MB.
KeyDB: ~720 MB.
Dragonfly: ~430 MB.

Dragonfly использует более компактные структуры и собственный allocator. На больших объёмах это уже заметная разница: с 32 GB RAM можно держать в полтора раза больше горячих данных. Для in-memory кэша — большой плюс.

Поведение при падении

Я честно прибивала процессы и смотрела, как они восстанавливаются.

Redis с RDB+AOF восстанавливается до текущего состояния. AOF append даёт небольшой оверхед, но это стандарт.
KeyDB ведёт себя так же. С их репликацией active-active я не баловалась — мне не нужна.
Dragonfly snapshot работает с COW (copy-on-write на форке) и snapshots компактнее. AOF тоже есть, у меня жалоб не было.

На простом сценарии «один инстанс на VPS» все три ведут себя достойно.

Что я в итоге беру

Redis

Беру по умолчанию. Если у меня небольшой сервис, важна максимальная совместимость, или я работаю с экосистемой плагинов RediSearch/RedisJSON. Большинство managed-предложений у российских и зарубежных хостеров — именно Redis.

Когда выбираешь между «всё работает из коробки» и «потенциально на 10% быстрее» — на Redis 7 с tweaked-конфигом (включил io_threads, отключил THP, оставил AOF в everysec) ты получишь production-grade сервис без сюрпризов.

KeyDB

Беру, если хочется multi-thread без переписывания приложения. KeyDB полностью совместим с Redis: меняешь endpoint и забываешь. На своём железе с 4–8 ядрами разгонит throughput, не требуя кластера. Хорош для:

BullMQ под высокую нагрузку.
Активного pub/sub с большим количеством subscriber-ов.
Кейсов, где не хочется городить Redis Cluster, но один процесс уже не справляется.

Минус KeyDB — проект развивается медленнее, чем хотелось бы. Часть PR от сообщества месяцами висит. Для большой компании это может быть стоп-фактор.

Dragonfly

Беру, если у меня большой кэш по памяти, и я уверена, что мои команды совместимы. Хорошо подходит для:

Многоинстансного in-memory кэша на сервисах в кубере.
Сторонних KV-сценариев: счётчики, sorted sets, простые геозапросы.
Замены memcached с расширенным функционалом.

Не беру под BullMQ и под места, где используется хитрая Lua-логика. И помни, что часть Redis-расширений (search, json) у Dragonfly в виде встроенных команд, но не идентичны Redis-плагинам — синтаксис может отличаться.

Конфиг, который использую под Redis

Чтобы не повторять для каждого нового инстанса, у меня есть базовый /etc/redis/redis.conf:

bind 127.0.0.1
port 6379
protected-mode yes
requirepass <long-password>
maxmemory 1gb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec
io-threads 4
io-threads-do-reads yes
rdb-save-incremental-fsync yes

На VPS я обязательно добавляю отключение transparent huge pages:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

Redis сильно жалуется в логе на THP, и не зря: производительность под нагрузкой может проседать в разы.

Конфиг, который использую под KeyDB

То же самое, что Redis, плюс многопоточность:

server-threads 4
server-thread-affinity true

server-thread-affinity привязывает потоки к ядрам, что на VPS с фиксированными vCPU работает чуть стабильнее.

Конфиг Dragonfly

У Dragonfly нет файла конфигурации, всё через флаги командной строки. Я обычно поднимаю в systemd-юните:

ExecStart=/usr/bin/dragonfly \
  --bind 127.0.0.1 \
  --port 6379 \
  --maxmemory 1gb \
  --cache_mode true \
  --requirepass <long-password> \
  --logtostderr

Флаг --cache_mode true включает аналог allkeys-lru: когда память заполнилась, ключи вытесняются автоматически. Очень удобно как простой кэш.

Вопрос managed

В России managed Redis есть у Yandex Cloud (Yandex Managed Redis), Selectel и Timeweb Cloud. У всех — обычный Redis, KeyDB/Dragonfly не предлагают. Если тебе нужно managed решение, выбора фактически нет: Redis. Что касается совместимости, твоё приложение продолжит работать без изменений, если ты сам захочешь переехать на KeyDB или Dragonfly на своих серверах.

Вывод

В трёх предложениях:

Redis — стандарт, совместимость и предсказуемость.
KeyDB — Redis с правильной многопоточностью, идеален как drop-in замена.
Dragonfly — самый быстрый и компактный, но проверь совместимость с твоими командами.

В моих сервисах сейчас стоит KeyDB на одном проекте, Redis на трёх (включая managed) и Dragonfly как отдельный кэш на одном — и это нормальный микс. Идеального варианта нет, выбирай по нагрузке и привычкам команды.