Привет, Хабр!

Многие из нас использовали Redis годами как кеш, брокер коротких сообщений или хранилище сессий, поднимали его в Docker, в Kubernetes или покупали в облаке. Думаю немногие читали LICENSE тк «Redis = BSD, значит всё можно». В марте 2024 для новых версий это изменилось.

За два года экосистема раскололась: Redis Inc. сменила лицензию ядра, Linux Foundation запустила Valkey, облака массово перешли на форк, а в Redis 8 появился третий вариант лицензии - AGPLv3.

Тема более чем актуальная: недавно на Хабре вышла статья Яндекса «Valkey и Redis: два года спустя - за кем будущее?». В ней больше про развитие Valkey как продукта, новые фичи и позицию облачного провайдера. Здесь я смотрю на вопрос с другой стороны: что произошло с лицензией Redis, кого это реально задевает и какой вариант выбрать продуктовой команде, использующей его в составе системы.

Если вы решили разобраться с этой темой как и я, то велкам под кат !

Что вы узнаете

  1. Краткая хронология - что случилось с Redis с 2024 по 2026 год

  2. Что было до 2024

  3. На что поменяли лицензию ядра - RSALv2, SSPLv1 и почему это уже не обычный open source

  4. Что изменил Redis 8 - зачем появилась AGPLv3 и что значит tri-license

  5. Почему Redis Inc. это сделала - официальная версия и бизнес-причины

  6. Кого это затрагивает - self-hosted, SaaS, облака, дистрибутивы и managed-сервисы

  7. Какие есть альтернативы - Valkey, KeyDB, Dragonfly, Garnet и чем они отличаются

  8. Что ломается при переходе - модули, версии, кластер, облака, клиенты и юридические проверки

  9. Что выбрать в 2026 году - когда брать Valkey, Redis 8, Dragonfly, KeyDB или Garnet

1. Краткая хронология

2009–2024     Ядро Redis - BSD 3-Clause
2018–2019     Модули Redis Stack → RSAL (RediSearch, JSON и др.)
20.03.2024    Анонс: с Redis 7.4 ядро → RSALv2 + SSPLv1
28.03.2024    Linux Foundation объявляет Valkey (форк 7.2.4, BSD)
05.2025       Redis 8.0: tri-license (+ AGPLv3), Stack-модули в ядре

Redis 7.2.x и ниже остаются под BSD навсегда - их никто не «отзывает». Но новые фичи, security-fix’ы в свежих ветках и managed-сервисы облаков уже под новой лицензией.

2. Что было до 2024: BSD и «модули - отдельно»

Ядро

С момента создания Salvatore’ом Sanfilippo (ник antirez) ядро Redis распространялось под BSD 3-Clause.

BSD 3-Clause - одна из самых свободных open source лицензий:

  • можно использовать в коммерческих продуктах;

  • можно модифицировать и не открывать изменения;

  • можно встраивать в проприетарный код;

  • облако может продавать managed Redis без согласования с автором.

Именно поэтому Redis так быстро стал инфраструктурным стандартом. Никакого copyleft, никаких «если отдаёшь по сети - открой код».

Copyleft - принцип лицензии, при котором изменения в коде нужно распространять под такой же или совместимой открытой лицензией. У BSD такого требования нет.

Модули

Ещё в 2018–2019 Redis Labs (ныне Redis Inc.) начала ограничивать модули, а не ядро:

  1. 2018 - модули (RediSearch, RedisGraph, RedisJSON, RedisBloom, RedisML) ушли с AGPL на Apache 2.0 + Commons Clause (запрет продавать как сервис).

  2. 2019 - Commons Clause заменили на RSAL (Redis Source Available License), чтобы явно не называть это open source.

AGPL - open source лицензия с сильным copyleft. Если модифицированную программу дают пользователям по сети, исходники изменений тоже нужно открыть.

Apache 2.0 + Commons Clause - Apache 2.0 сама по себе свободная open source лицензия, но Commons Clause добавляет запрет на продажу ПО как продукта или сервиса. Поэтому такая связка уже не считается полноценным open source.

Компания тогда публично обещала: «ядро Redis всегда будет под BSD». В 2024 это обещание для новых версий ядра перестало выполняться.

3. Смена лицензии ядра: RSALv2 и SSPLv1

20 марта 2024 Redis Inc. объявила: начиная с Redis 7.4, ядро распространяется под двумя source-available лицензиями - на выбор:

Лицензия

Суть

RSALv2

Можно использовать, модифицировать, встраивать в приложения. Нельзя предлагать как конкурирующий database/cache/search/stream engine as a service

SSPLv1

MongoDB-стиль: если предлагаешь как managed service - нужно открыть весь стек, через который пользователь получает доступ к ПО

Открыть весь стек - значит раскрыть не только изменения в Redis, но и код сервисов, API, панелей управления, биллинга и другой инфраструктуры, через которую клиент получает managed-сервис.

Обе лицензии не одобрены OSI как open source. Redis Inc. сама перестала называть продукт «open source edition» и ввела термин Redis Community Edition.

OSI (Open Source Initiative) - организация, которая поддерживает стандартное определение open source и список одобренных лицензий. Если лицензия не одобрена OSI, её обычно не считают полноценной open source лицензией.

Что изменилось в продукте

  • Redis 7.2 и ниже - по-прежнему Redis OSS, BSD.

  • Redis 7.4+ - Redis Community Edition, RSAL/SSPL.

  • Начиная с Redis 8 планировалось (и случилось) влить Redis Stack (JSON, Search, TimeSeries и др.) прямо в Community Edition - раньше они были отдельными модулями под RSAL.

Практический смысл SSPL и RSAL для обычного разработчика

Если вы поднимаете Redis как кеш для монолита или микросервисов - формально RSAL/SSPL вас почти не ограничивают.

Если вы продаёте свой SaaS-продукт, а Redis используется внутри это обычно не считается продажей Redis как сервиса.

Проблемы начинаются когда:

  • клиент получает Redis-compatible endpoint или управляемый cache/database как отдельную часть вашего продукта

  • вы продаёте managed in-memory store клиентам;

  • вы упаковываете Redis в свой database-as-a-service;

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

  • дистрибутив (Debian, Fedora) не может включить пакет с SSPL.

4. Redis 8 и возвращение AGPLv3

Через год после скандала Redis Inc. сделала частичный разворот. Redis 8.0 (май 2025) получил третью лицензию - AGPLv3. Теперь Redis 8+ tri-licensed: RSALv2 / SSPLv1 / AGPLv3 на выбор.

Tri-licensed значит, что у одной версии продукта есть три лицензии, а пользователь выбирает, на условиях какой из них использовать продукт.

Это важно:

  • AGPLv3 - OSI-approved open source. Формулировку «Redis больше не open source» для ветки 8.x уже нельзя применять буквально.

  • Но AGPL - copyleft. Если вы модифицируете Redis и отдаёте его пользователям по сети (типичный SaaS), есть обязанность раскрыть исходники модификаций. BSD такого не требовал. Не SSPL-уровень «открой весь стек», но юристы часто смотрят на AGPL под лупой.

  • Возвращение antirez в Redis Inc. (конец 2024) и рост метрик компании - часть официального нарратива «форки достигли цели, мы вернули open source path».

Параллельно Redis 8 принёс инженерные изменения: Stack-модули в ядре, vector sets, заявленный прирост throughput. Но облака (AWS, GCP, Oracle) к этому моменту уже закрепили Valkey как движок managed-сервисов.

5. Почему Redis Inc. это сделала

Официальная версия из блога: cloud providers годами зарабатывали на managed Redis, не финансируя разработку upstream. Redis Inc. хочет «fair licensing agreements» - Microsoft уже заключил сделку; AWS и Google предпочли форк.

Если сказать проще, дело в бизнесе:

  1. Бизнес-модель. Redis Inc. продаёт Redis Enterprise, Redis Cloud и коммерческие лицензии. Бесплатный BSD-Redis в AWS ElastiCache конкурировал с их выручкой.

  2. Прецедент рынка. MongoDB (SSPL, 2018), Elasticsearch (Elastic License, 2021), HashiCorp (BSL, 2023) - все пошли по похожему пути. Redis не исключение.

BSL (Business Source License) - лицензия, при которой код открыт для чтения, но часть коммерческого использования ограничена. Обычно через несколько лет конкретная версия переходит на свободную лицензию.

  1. Модули уже были закрыты. Перенос RSAL/SSPL на ядро логически продолжил политику 2019 года, просто затронул то, что все реально используют.

CEO Rowan Trollope в марте 2024 прямо говорил, что не удивится, если Amazon спонсирует форк. Через восемь дней Linux Foundation анонсировала Valkey.

6. Кого это затрагивает на практике

Self-hosted: команда с Docker/K8s и обычным кешем

Минимальное влияние, если:

  • вы на Redis 7.2 BSD или Valkey;

  • не модифицируете исходники Redis;

  • не перепродаёте Redis как сервис.

Среднее влияние, если:

  • у компании есть правило использовать только лицензии, одобренные OSI: Redis 7.4+ под RSAL/SSPL не подойдёт, а Redis 8 под AGPL придётся отдельно согласовать с юристами;

  • хотите свежие фичи Redis 8 (vector search в core) - придётся принять tri-license.

SaaS и продуктовые компании

Если ваш продукт отдаёт Redis наружу (multi-tenant cache as a feature, embedded database для клиентов):

  • BSD / Valkey - максимальная свобода;

  • AGPLv3 (Redis 8) - copyleft на модификации, отданные по сети;

  • SSPL - теоретически «открой весь backend»;

  • RSAL - запрет на конкурирующий database-as-a-service.

На практике решение по AGPL часто зависит не от архитектуры, а от правил компании. В одном случае Redis 8 могут разрешить как внутренний кеш, если зафиксировать, что клиентам он не отдаётся. В другом - запретить просто потому, что в компании нельзя использовать AGPL.

Облачные провайдеры

Именно ради них и затевалось. AWS заменил движок в ElastiCache/MemoryDB на Valkey, Google - аналогично, Oracle - тоже. Managed «Redis» в облаках часто уже Valkey под капотом, даже если в интерфейсе всё ещё написано Redis.

Дистрибутивы Linux и пакетные менеджеры

Debian, Fedora и ряд других дистрибутивов не принимают SSPL как свободную лицензию. После 7.4 пакет redis в distros либо застрял на 7.2.x, либо заменён на Valkey. Если вы выполняете apt install redis-server - проверьте, что именно ставится.

Те, кто уже на managed cloud

Часто миграция прозрачна: провайдер сам переключил backend. Connection string тот же, протокол RESP совместим. Не прозрачна - если вы завязаны на Redis-специфичные команды модулей, которых в Valkey ещё нет.

RESP (Redis Serialization Protocol) - протокол, по которому Redis-клиенты общаются с сервером. Если другой сервер поддерживает RESP, те же клиентские библиотеки часто работают без переписывания кода.

7. Форки: Valkey, KeyDB, Dragonfly, Garnet

После марта 2024 рынок Redis-compatible серверов распался. Вместо одной замены Redis появилось несколько вариантов с разной лицензией, архитектурой и зрелостью.

Valkey - главный наследник BSD-Redis

Старт

28 марта 2024, Linux Foundation

База

Fork Redis 7.2.4 (последний BSD tag)

Лицензия

BSD 3-Clause

Кто поддерживает

AWS, Google Cloud, Oracle, Ericsson, Snap, Alibaba

Управление проектом

Технический комитет Linux Foundation

Valkey может заменить Redis без больших изменений: те же клиенты (Jedis, Lettuce, redis-py, ioredis), тот же протокол RESP, replication, cluster, persistence. AWS и GCP ставят его default’ом в managed-сервисах.

Плюсы: BSD без дополнительных ограничений, активная разработка, multi-threaded I/O, улучшения кластера, vector search в roadmap/релизах.

Минусы: нет некоторых Redis 8 фич «из коробки»; Redis Enterprise active-active CRDT - отдельная история; экосистема модулей Redis Stack не переносится один в один.

Active-active CRDT - режим, где несколько кластеров могут принимать записи одновременно, а данные потом автоматически сходятся к одному состоянию. Обычно это нужно для multi-region систем.

KeyDB - multi-threaded fork, сейчас в тени

Старт

2019, Snap Inc. (купили в 2022)

База

Fork Redis, multi-threading

Лицензия

BSD 3-Clause

Фишка

Active-active multi-master, FLASH (tiered storage на диск)

Active-active multi-master - схема, где несколько узлов могут принимать запись одновременно, без одного главного сервера. Это удобно для распределённых систем, но сложнее в настройке и конфликтных сценариях.

KeyDB был «быстрый многопоточный Redis» задолго до Valkey. После 2024 основное внимание ушло к Valkey: туда пришли облачные провайдеры, Linux Foundation и часть бывших Redis-maintainer’ов. KeyDB жив, но о нём говорят заметно меньше. Имеет смысл, если нужен именно active-active на open source без Enterprise - но сначала прогоните его на своих тестах и нагрузке.

Dragonfly - не форк, а reimplementation

Старт

2022, DragonflyDB Inc.

База

C++ с нуля, RESP-compatible

Лицензия

BSL 1.1 → Apache 2.0 после 4 лет (для каждой версии)

Фишка

Shared-nothing multi-threading, заявленный 25× throughput на одной ноде

Dragonfly - не «Redis с другой лицензией», а другой движок с совместимым протоколом. На бенчмарках часто обгоняет Redis/Valkey на одной машине. Зато:

  • BSL запрещает продавать Dragonfly как конкурирующий managed-сервис;

  • cluster mode исторически слабее Redis Cluster;

  • не все команды и edge cases совместимы на 100%.

Хорош для self-hosted high-throughput, когда одной ноды хватает и юристы не против BSL.

Garnet - Microsoft Research, .NET

Старт

Март 2024

База

C# / .NET, поверх FASTER KV

Лицензия

MIT

Фишка

Может хранить данные в памяти и на диске, упор на высокую скорость

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

Garnet вырос из исследовательского проекта Microsoft Research. MIT лицензия максимально свободна. Поддерживает подмножество Redis-команд (strings, lists, sets, sorted sets, hashes). Нет полноценного Redis Cluster, зрелость ниже. Azure тестировал «Garnet for Azure Cache». Интересен для .NET-стека и экспериментов, не как default replacement для production Redis Cluster.

Сводная таблица

Redis 8

Valkey

KeyDB

Dragonfly

Garnet

Лицензия

RSAL/SSPL/AGPL

BSD

BSD

BSL→Apache

MIT

OSI open source

Только AGPL

Да

Да

Нет (пока BSL)

Да

Managed SaaS без ограничений

Нет (кроме AGPL copyleft)

Да

Да

Нет

Да

Кодовая база

Redis Ltd.

Fork 7.2.4

Fork Redis

С нуля

С нуля

Multi-threading

I/O threads

I/O + улучшения

Да

Да, core design

Async

Cluster

Зрелый

Работает, есть улучшения

Partial

Partial

Нет

Multi-master

Enterprise only

Нет

Да

Нет

Нет

Stack modules (JSON, Search)

В core (Redis 8)

Отдельно / community

Не встроены, проверять отдельно

Нет

Нет

8. Сложности перехода

Протокол RESP совместим - но «поменять connection string» работает только для простого кеша. На практике всплывает больше.

8.1. Redis Stack и модули

Если вы используете RediSearch, RedisJSON, RedisTimeSeries, RedisGraph - это больная точка.

  • В Redis 8 часть встроена в core под новой лицензией.

  • В Valkey - отдельные projects (например Valkey Search/Bloom), API похож, но не идентичен; миграция индексов и запросов требует тестов.

  • RedisGraph больше не развивается и не поддерживается - ищите замену (Neptune, Memgraph, свой граф).

Я бы заложил отдельный спринт только на модули, если Search/JSON - не «nice to have», а core functionality.

8.2. Версионный разрыв

Valkey форкнулся с 7.2.4. Redis ушёл в 7.4 → 8.0 с другим набором команд и оптимизаций. Команды вроде новых структур Redis 8 могут отсутствовать в Valkey (и наоборот - Valkey добавляет своё).

Что делать: прогнать integration tests + redis-cli --scan + snapshot команд из slowlog production. На сайте Valkey есть таблица совместимости, но ваш код может использовать редкие команды.

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

8.3. Кластер и обслуживание

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

  • Резервные копии и восстановление: файлы RDB/AOF в основном совместимы между Redis 7.2 и Valkey, но восстановление лучше заранее проверить на тестовом стенде.

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

8.4. Облачные сервисы и цены

AWS ElastiCache заявлял, что Valkey может быть на 20–33% дешевле, чем Redis-движок. Точная экономия зависит от региона и типа инстанса. Перед переходом всё равно нужно проверить окно миграции, группы параметров и версию движка. В Google Cloud Memorystore и Oracle OCI перед переходом нужно проверить те же вещи: версию движка, параметры сервиса, миграцию и цену.

8.5. Клиентские библиотеки

Jedis, Lettuce, go-redis, redis-py - работают с Valkey без изменений для базовых сценариев. Проблемы начинаются с:

  • клиентов, hardcode’ящих REDIS_VERSION checks;

  • TLS/SACL/ACL различий между версиями;

  • Redis Enterprise-specific API.

8.6. Юристы и закупки

Даже если технически миграция простая, её могут задержать юристы или отдел закупок:

  • «Redis» в договоре с вендором - а поставляют Valkey;

  • политика «no AGPL» блокирует Redis 8;

  • SBOM и supply chain audit требуют BSD/MIT/Apache.

SBOM (Software Bill of Materials) - список компонентов, из которых состоит продукт: библиотеки, образы, версии и лицензии.

Supply chain audit - проверка всей цепочки компонентов продукта: какие библиотеки, сервисы, образы и инструменты используются, какие у них лицензии и риски.

8.7. Лицензия старых инстансов

Redis ≤7.2 остаётся BSD. Можно не мигрировать технически, но:

  • нет security patches в community ветке (Redis Ltd. backport’ит в Enterprise);

  • новые CVE закрываются в 7.4+/8.x или Valkey;

  • оставаться на Redis 7.2 надолго рискованно.

9. Что выбрать в 2026 году

Единого правильного выбора нет - всё зависит от вашего сценария.

Valkey - default для новых проектов, self-hosted и cloud-managed, если нужен классический Redis без лицензионной головной боли. BSD, совместим с Redis-клиентами, поддержка крупных облачных провайдеров.

Redis 8 (AGPLv3) - если нужны встроенные vector search, JSON, time series в одном бинарнике от Redis Ltd., юристы согласовали AGPL, и вы не продаёте конкурирующий Redis-сервис.

Redis 7.2 BSD - только если пока не можете перейти; не как стратегия на годы.

Dragonfly - одна fat-нода, BSL acceptable, нужен throughput выше Valkey/Redis; cluster не критичен.

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

Garnet - если у вас .NET-стек, Azure или вы готовы экспериментировать; не замена зрелому cluster.

Вывод

Redis остался Redis, но старая привычная формула «Redis = BSD, можно всё» больше не работает.

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

Главное - не обновляться вслепую. После 2024 при выборе Redis нужно смотреть не только на фичи, но и на лицензию.

Источники

Если статья заинтересовала, то можно еще почитать мой блог.

Спокойных Вам релизов !