Valkey и Redis: два года спустя — за кем будущее?

Всем привет! Меня зовут Владимир Гошев, начну с краткой справки. Я много администрировал всё — от localhost до геораспределённых кластеров, писал компилятор, и сейчас руковожу командой, которая занимается разработкой нереляционных управляемых СУБД в технологической платформе Yandex Cloud. В том числе, наша команда занимается разработкой одного из инструментов, но оставим интригу. 

Можно сказать: trust me, I'm an engineer.

В марте 2024 года Redis сменил лицензию и, тем самым, положил начало развитию Valkey. Два года Valkey активно развивался: набирал количество контрибьютеров, коммитов, был встроен в многие проекты — в общем, показал себя на практике. Пришло время подвести итоги и понять: есть ли в этом сравнении победитель.

В статье разберем обе технологии. Будет немного про историю развития и хронологические предпосылки, разбор ключевых фич и почти детективное расследование о жизни двух хранилищ. Также, покажем за кем будущее (по нашему мнению) и зачем мы контрибьютим в одно из них.

Что такое Valkey?

Valkey — это форк Redis. Про Redis слышали многие, но уточню: это база данных типа «ключ-значение», которая всё хранит в памяти. Это делает её очень быстрой, но одновременно дорогой, потому что память сильно дороже диска. 

Redis родился в 2009 году, написан на C. Фан-факт: его предшественник LMDB был написан на TCL, и тесты для Redis и Valkey до сих пор на TCL — от чего страдают не только программисты, но и некоторые котята.

Redis изначально был BSD-лицензированным, потом появилась компания Redis Ltd., и в марте 2024 года она решила перейти на source available-лицензию — закрытую как минимум для облаков. Либо вы платите и можете предоставлять Redis как сервис, либо не можете. Такие лицензии не имеют обратной силы, и коммит перед сменой лицензии остался BSD, что позволило создать Valkey и другие форки.

Примерно через год Redis сделал полшага назад и добавил АGPLv3, но поезд уже ушёл — и для облаков всё равно нельзя было бы использовать Redis.

Когда Redis ушёл с BSD, это отпугнуло многих сторонних разработчиков. Доля контрибьюторов, не связанных с компанией Redis, в проекте была подавляющим большинством: много представителей AWS, Google Cloud и других. Им стало нецелесообразно разрабатывать продукт, которым они больше не могут пользоваться. Появились форки — Redict и Valkey. 

Небольшой спойлер: на мой взгляд, Valkey победил. Туда ушли AWS, Google, Percona, китайские облака — Alibaba, Tencent — и, конечно же, Yandex Cloud.

История Valkey

Valkey начал как обычный форк Redis 7.2 и за 2 года стал полноценным взрослым продуктом, у которого Redis уже заимствует наработки. BSD-лицензия это позволяет, к счастью или к сожалению.

Хронология:

• 16 апреля 2024 — первая версия, которая не сильно отличалась от Redis 7.2. Появился Valkey 7.2.5, и форк начал быстро развиваться, потому что ему никто не мешал. Как оказалось, компания Redis ltd. душила инициативы, которые мешали их бизнесу: если кто-то хотел добавить в комьюнити-версию что-то, что составляло конкуренцию их enterprise-версии — они тихо-мирно не пропускали такие pull-requests. К сожалению, это довольно распространенная ситуация в подобных проектах. 

• 16 сентября 2024 — релиз Valkey 8.0, новой мажорной версии с улучшением производительности, работы с памятью, многопоточности.

• Июль 2025 — выход Valkey Search, модуля для векторного и полнотекстового поиска с плагинами для Bloom-фильтров и работы с JSON, что сделало feature-compatibility с Redis.

• Октябрь 2025 — Valkey 9.0: атомарная миграция слотов, поддержка нескольких баз данных в кластерном режиме, Hash Field Expiration и другие улучшения производительности.

• Май 2026 — появление Valkey 9.1: снижение потребления памяти до 10% без перенастройки, автоматическая перезагрузка TLS-сертификатов и DB-level ACL — управление правами пользователей на уровне отдельных баз данных внутри инстанса.

Теперь должно быть понятнее, что Valkey действительно развивается семимильными шагами и что он из себя представляет.

Почему Valkey — это круто

Лицензия 

Не самый важный момент для пользователя, но важный идеологически. У Valkey лицензия BSD, то есть код можно использовать как угодно: раскрывать или не раскрывать исходники, тырить или добавлять код — никто вас не обвинит ни в чем. И эта лицензия, скорее всего, никогда не поменяется по двум причинам:

• проект разрабатывают облака, которым невыгодна закрытая лицензия; 

• он под покровительством Linux Foundation — бюрократия не позволит поменять лицензию за разумное время. Есть у бюрократии и полезные свойства.

Не менее важный фактор заключается в том, что его разрабатываем мы. А это всегда важное преимущество любого проекта, иначе бы мы это не разрабатывали. 

Dual channel replication

Раньше в Redis при добавлении новой реплики в кластер происходило следующее: реплика подключалась к мастеру, мастер делал дамп всей памяти и пересылал его. Пока дамп снимается и пересылается, копится буфер с новыми данными, память растёт — и это часто приводило к OOM из-за нехватки памяти. В итоге падала либо наливка реплики, либо весь процесс целиком. 

В Valkey придумали, возможно, очевидную, но очень простую штуку: реплика при полной наливке подключается вторым потоком и сразу скачивает все изменения. В итоге память растёт не на мастере, а на новой реплике. Это стабилизирует мастер и ускоряет процесс, потому что скачивание дампа и изменений идёт одновременно. А ещё это просто классно.

IO-Threads Work Offloading

Изначально Redis однопоточный — это делает его простым и надёжным, но задаёт ограничения на один поток и очень усложняет вертикальное масштабирование. В какой-то момент операции ввода-вывода (IO) вынесли в отдельные потоки, потому что работа с сетью и диском — это очень медленно. Но процессор при этом простаивает. Вынесли, стало чуть лучше, но не до конца.

В Valkey пошли дальше и вынесли в потоки многие другие операции. Яркий пример — TLS-хендшейки. Не будем вдаваться в подробности, но установление соединения через TLS — это очень дорого. Если сеть пофлапалась и все клиенты отключились, а затем разом ринулись на сервер, однопоточный процесс просто упадёт. При вынесении в потоки всё распараллеливается.

Кроме очевидного базового улучшения, ещё и оптимальнее утилизируются ресурсы: на современном многопроцессорном сервере задействуются все ядра, а не одно.

Refactor of ActiveDefrag

Следующее — это рефакторинг в активной дефрагментации памяти, который сделал её лучше. Вспоминая институт, дефрагментация памяти кажется бессмысленной, потому что доступ к любой точке памяти одинаковый по времени: нет штрафа по сравнению с HDD-дисками. Но, как всегда, есть нюанс: когда нужно выделить память, нужен цельный кусок. Если память сильно фрагментирована, цельного куска может не быть, даже если свободной памяти формально много. В этот момент становится понятно, что дефрагментация памяти имеет смысл.

Возможность дефрагментации была и раньше, но её включение роняло производительность на десятки процентов — на проде такое никто не включит. В Valkey отрефакторили и оптимизировали: падение производительности составляет единицы процентов в худшем случае, а в лучшем — ноль.

Случай из жизни: к нам пришёл клиент, у которого данных было сильно меньше, чем потребляемая память. Стали выяснять причину и выяснилось, что решение простое: «Обновитесь до новой версии, включите активную дефрагментацию, и, кажется, вам будет хорошо». После обновления до новой версии и включения активной дефрагментации потребление памяти упало в 3 раза.

Multi-database support in claster mode

Немного про шардирование. В большинстве СУБД внутри кластера можно создавать отдельные логические базы данных. В Valkey вместо человекочитаемых имён используются индексы: 0, 1, 2, 3... В конфиге указывается, сколько будет БД. Если раньше при шардировании шардировалась только нулевая база данных, то в Valkey сделали так, что любая база данных с любым индексом может шардироваться. Многим стало сильно лучше.

Atomic slot migration

Шардирование в Valkey и Redis устроено так: все ключи разбиты на ~16 000 слотов, чтобы получить нужный слот, достаточно взять CRC16. Клиент подключается, узнаёт, на каком шарде находится нужный слот, идёт туда и получает или кладет данные.

Когда нужно было добавить шард или перебалансировать нагрузку, раньше это работало так: блокируете слот на запись, переносите данные на новый шард, меняете владельца, разблокируете. Если данных много — десятки секунд или минуты простоя на запись.

Начиная с версии 9 в Valkey новый шард становится репликой конкретного слота и реплицирует. Когда репликация сходится, слот блокируется на миллисекунды — ровно чтобы репликация догнала. Меняется владелец, слот разблокируется. Простой составляет единицы миллисекунд, иногда близок к нулю.

Дополнительно добавили метрики слотов, что позволяет делать умную балансировку не только по памяти, но и по CPU, сети и другим ресурсам.

Redis ворует наработки Valkey

Я уже упоминал, что Redis тырит наработки. Если в репозитории Redis поискать слово «valkey», найдётся 61 файл и 69 пулл-реквестов — это просто копирайт, указывающий на авторов из команды Valkey. Простой поиск наглядно доказывает моё заявление.

Интересный момент: кто-то пытался делать обратное — тащить код из Redis в Valkey, но лицензия Redis это запрещает. Доблестные мейнтейнеры это заметили, коммит откатили, и после этого в репозитории появился механизм проверки по хэшам — не стырено ли что-то из Redis.

Сравнение за 2 года (март 2024 — март 2026)

Небольшое сравнение, чтобы показать, насколько быстро развивается Valkey. Взял данные именно за два года, чтобы было что сравнивать.

За это время в Valkey по сравнению с Redis:

• на 80% больше коммитов и коммиттеров;

• в 2,5 раза больше изменённых файлов;

• на 70% больше добавленных строк;

• в 6,5 раз больше строк удалено — то есть активнее избавляется от legacy.

Последняя маленькая победа заключается в том, что Ubuntu перешёл на Valkey. Следовательно, он начинает побеждать на свободном рынке.

Как вкатиться в опенсорс: история одного пулл-реквеста

Надеюсь, вы уже поняли, что Valkey – это классно. Возможно, кто-то даже захотел принять участие в разработке. Самое время рассказать историю о том, как мы скатились до разработки Valkey. 

Когда мы переходили на Valkey, мы писали свой агент отказоустойчивости, потому что ванильный нам не нравился. Сейчас для этого мы патчим Valkey, и хочется максимально удешевить их поддержку, поэтому мы стараемся хотя бы часть из них влить в ваниль.

Просто ворваться с улицы и принести какие-то патчи, которые, скорее всего, бессмысленны для среднестатистического пользователя — плохая стратегия, вас отправят обратно. Тогда, у нас созрел план: приходим, вежливо стучимся, наносим много пользы, становимся знаменитыми и потом стараемся качать права.

К нашему счастью, в тот момент в команду пришёл разработчик Даниил Кашапов и сказал, что хочет писать в Valkey. Мы выбрали задачу, полезную и нам, и сообществу: issue про ACL.

В Valkey, как и в большинстве баз данных, есть управление правами, но изначально оно распространялось на все базы данных одинаково — у пользователя не было разных прав для базы 0 и базы 1. Конечно, это подходило далеко не всем. Тогда мы сделали поддержку ACL per database.

Таймлайн:

• 4 июля 2025 — принесли PR. Так как это было нужно обществу, началась дискуссия.

• Через 10 дней мейнтейнеры пришли и сказали: «В целом классно, вот исправьте кое-что, а мы как-нибудь замерджим». Уже маленькая победа. 

• Август — мы кое-что поправили, но мейнтейнеры пропали: готовили версию 9.

• Сентябрь — к нам пришли и сказали: «Мы про вас помним. Мы вам позвоним. Может быть, когда-нибудь».

• Конец октября — вышла 9.0, все выдохнули. Мейнтейнеры вернулись к PR говорят: «Всё классно, но переделайте». Мы переделали. Приходит другой мейнтейнер и сообщает, что всё классно, но нужно вернуть как было.

• По итогу завязалась большая дискуссия: 206 сообщений в обсуждении, но компромисс был найден. 

• 23 декабря — PR наконец замерджили и заодно сломали сайт Valkey. 

Как это произошло? Очень просто: замерджили PR — надо поправить документацию. Поправили и всё сломали. Я считаю это хорошим достижением. Кому вообще позволено сломать сайт мирового масштаба? Никому, а вот мы смогли. Ну и потом, естественно, починили.

По итогу полугодового путешествия наш разработчик замержил 23 PR на момент скриншота (с попутно пофикшеными багами) и стал довольно узнаваемым в комьюнити.

Что ещё мы делаем для Valkey

Раз уж я начал рассказывать, что мы делали, то продолжу. 

Если вы хотите влиться в open source, не обязательно разрабатывать саму базу, можно разрабатывать что-то вокруг базы, полезное всем. 

RDSync — агент отказоустойчивости 

Изначально, что у Redis, что у шардированного и нешардированного Valkey — у всех разные способы поддержания отказоустойчивости. Для нешардированного используется внешний агент Sentinel, который как-то внутри договаривается и выбирает маску мастера (или не выбирает, к сожалению).

В шардированном варианте мастера, которые выбирают, кто будет новым мастером у шарда, у которого кончился мастер. 

В нешардированном варианте было две проблемы:

• Два хоста — это не отказоустойчиво. Если один хост выпадает, второй не может сам выбрать себя новым мастером.

• Каскадная репликация не чинится. Сама по себе каскадная репликация может быть полезной, но в таком сценарии приводит к неприятным ситуациям. Например, реплики реплицировались друг от друга по цепочке, мастер уже ушел, но все считают, что всё в порядке. По факту мастера в кластере нет.

В шардированном варианте тоже были проблемы.

Очевидная: один или два шарда — это не отказоустойчиво. Если шард один и он выпадает, голосовать просто некому. Если шардов два, то при выпадении одного мастера кворум тоже разваливается.

Но была и менее очевидная проблема. В процессе жизни кластера все мастера могли постепенно оказаться в одной зоне доступности. Если эта зона падала, кластер обезглавливался: хостов в целом могло оставаться много, но выбрать новых мастеров было некому.

В нашем агенте мы это починили за счет внешнего кворума. В итоге отказоустойчивыми стали и конфигурации с двумя хостами, и кластеры с одним-двумя шардами. Особенно это полезно для кластеров с четным количеством шардов. При разделении сети пополам такая схема тоже обрабатывается нормально.

Последняя фича не связана с отказоустойчивостью, но разработка агента позволила нам создать ещё кое-что. 

Valkey хранит данные в памяти. Но обычно никому не хочется, чтобы при любом перепаде электричества данные просто исчезали. Поэтому Valkey и Redis позволяют сохранять данные на диск. 

Проблема в том, что при записи на диск вы начинаете упираться в диск. Для базы данных, которая работает в памяти, это очень медленно.

Мы подумали, что, если на мастере отключить запись на диск, а на репликах включить, то получается компромисс. Но у такой схемы есть большая проблема. Если мастер по кругу сменится, может получиться так, что персистентность везде окажется отключенной. Тогда данные можно потерять.

С нашим агентом эта проблема решена, и схема работает.

Раз уж я говорил про open source: агент тоже open source, написан на Go и лежит на нашем GitHub. Им можно пользоваться, можно приносить пулл-реквесты. Мы всегда рады.

Wal-G — утилита для управления бэкапами. 

Изначально эта утилита для Postgres, мы добавили поддержку Valkey (раннее добавили и для Redis). Потом мы добавили поддержку бэкапа AOF’ом.

Изначально мы делали дамп памяти так же, как это делает реплика, и сохраняли его куда-нибудь. Потом подумали: зачем нагружать мастер, если при включенной персистентности можно просто забрать данные с диска?

Последним шагом добавили управление бэкапами шардированных кластеров.

Модуль LuaJIT — наша маленькая победа.

В Valkey есть встроенный модуль для Lua, с помощью которого можно делать, например, атомарные операции. Сам Valkey, как и Redis, не поддерживает транзакции в том виде, в котором иногда хочется: вы не можете стандартными командами к базе атомарно выполнить сложную операцию. А с Lua-скриптами можете. Ну и, кроме этого, на Lua можно делать много других вещей.

Проблема Lua, как и любого другого чисто интерпретируемого языка, в том, что он медленный. Самый очевидный вариант ускорения — just-in-time-компиляция. Для Lua, к счастью, есть LuaJIT. Это та же Lua, только с компиляцией. При первом прогоне он читает код, выполняет его, компилирует и сохраняет уже скомпилированный байт-код. После этого код может выполняться до десяти раз быстрее.

Все началось с того, что к нам пришли клиенты и сказали: «Lua работает медленно». Мы managed-service, поэтому пришлось разбираться и чинить: нашли LuaJIT и сделали им хорошо.

Сначала мы просто подменили Lua у себя, а потом принесли этот патч в комьюнити. Комьюнити сказало: «Идите нафиг, мы не хотим, идите отсюда». Это стандартная история для open source или вообще для любого проекта.

Но к версии 9.1 Lua вынесли в отдельный модуль — он стал подключаться как отдельная библиотека. И это хороший момент, чтобы снова принести свое решение. Поэтому мы сделали LuaJIT тоже модулем и снова принесли его в комьюнити, но в этот раз у нас уже был какой-то вес. На этот раз наши наработки взяли в организацию, и теперь мы разрабатываем это не сами у себя где-то под столом, а вместе со всем комьюнити под предводительством Valkey.

Вместо выводов

Каждый решает сам. Кто-то продолжает успешно пользоваться Redis, кто-то плюётся от Valkey — и это нормально.

Если убрать эмоции, разница сводится к нескольким измеримым вещам, о которых и была статья. Лицензия BSD против source-available — это вопрос не вкуса, а того, можете ли вы вообще использовать продукт в своём сценарии (например, отдавать как сервис из облака). За два года в Valkey на 80% больше коммитов и в 6,5 раз больше удалённых строк legacy. Dual-channel replication, многопоточный IO и переработанный ActiveDefrag — это не лозунги, а конкретные числа из разделов выше: у одного клиента потребление памяти упало втрое, а простой при миграции слота теперь измеряется единицами миллисекунд.

При этом мы выбрали Valkey и вкладываемся в него, поэтому объективным наш выбор не назовёшь — так честнее.

Берите Valkey, если вам важна открытая лицензия, вы упираетесь в один поток или во фрагментацию памяти, либо хотите влиять на развитие проекта. Оставайтесь на Redis, если вас всё устраивает или вы завязаны на его enterprise-фичи и модули, которых в Valkey пока нет: миграция ради миграции смысла не имеет.

Что мы будем делать с Valkey дальше — это отдельная история. Мы продолжаем контрибьютить и помогать встроить инструмент в работу — узнать о том, что получается, можно здесь.