Сообщество Valkey выпустило стабильную версию 9.1.0 — релиз с заметным акцентом на производительность, экономию памяти, безопасность и наблюдаемость. Для разработчиков и администраторов это не просто «ещё одно обновление»: Valkey 9.1 обещает до 2,1 млн запросов в секунду на одном сервере в тестовой конфигурации и добавляет инструменты, которые упрощают работу с кластерами, логами и правами доступа.
Стабильный релиз Valkey 9.1 вышел 19 мая 2026 года
Valkey 9.1.0 стал первым стабильным релизом ветки 9.1. На официальной странице релизов указана дата выхода 19 мая 2026 года, а в GitHub release notes релиз помечен как первая стабильная версия Valkey 9.1 с низкой срочностью обновления: это означает, что апгрейд важен, но не выглядит как экстренный патч, который нужно ставить немедленно на все системы.
Valkey — это высокопроизводительная in-memory база данных типа key-value. Проще говоря, она хранит данные в памяти и используется там, где важны очень быстрые ответы: кэширование страниц, сессии пользователей, очереди, временные токены, счётчики, рейтинги, события и другие данные, к которым приложение обращается постоянно.
Релиз важен для тех, кто использует Valkey или совместимые сценарии после ухода части экосистемы от Redis. В таких системах даже несколько процентов прироста производительности или экономии памяти могут заметно влиять на стоимость инфраструктуры: меньше серверов, меньше задержек, спокойнее пики нагрузки.
Официальные материалы по релизу доступны в анонсе Valkey 9.1, на странице релизов Valkey и в GitHub release notes.
Производительность стала главным практическим акцентом Valkey 9.1
Главная цифра релиза — до 2,1 млн запросов в секунду на одном сервере при 512-байтных payload, 9 I/O-потоках и глубине pipeline в 10 команд. Это не значит, что каждый реальный проект автоматически получит такой результат: производительность зависит от железа, сетевой задержки, типа команд, размера данных, настроек клиента и нагрузки. Но сама цифра показывает направление развития Valkey: проект продолжает оптимизировать не только отдельные команды, но и внутреннюю архитектуру обработки запросов.
В Valkey 9.1 переработана модель взаимодействия I/O-потоков. По данным проекта, это даёт прирост throughput до 17% для разных типов нагрузки. На практике это важно для сервисов, где Valkey обслуживает большой поток однотипных коротких операций: чтение кэша, запись сессий, проверка временных ключей, работа с очередями и быстрыми счётчиками.
Отдельно ускорены операции со Streams. Команды XRANGE и XREVRANGE могут работать до 30% быстрее благодаря оптимизации горячего пути выполнения. Streams часто используют для событийных сценариев: например, когда приложение пишет поток действий, задач или сообщений, а несколько обработчиков читают их в нужном порядке.
Для обычных строковых операций тоже есть улучшения. Увеличение порога embedded string до 128 байт может дать до 30% большей пропускной способности для GET. Это особенно заметно в кэширующих сценариях, где приложение постоянно читает небольшие значения: идентификаторы, флаги, короткие JSON-фрагменты, статусы, токены или компактные настройки.
Экономия памяти снижает стоимость кэша и горячих данных
Производительность Valkey важна, но для in-memory базы не менее критична память. Данные хранятся в RAM, а RAM обычно дороже дискового пространства. Поэтому снижение накладных расходов на хранение небольших значений может напрямую влиять на стоимость эксплуатации.
Valkey 9.1 оптимизирует внутренние структуры для маленьких строк. По данным проекта, для строк короче 128 байт возможна экономия памяти до 20%. Это очень практичное изменение: в кэше и сессионных хранилищах как раз часто лежат короткие значения, которые по отдельности малы, но в сумме занимают гигабайты.
Для sorted sets также заявлено снижение потребления памяти до 10% за счёт оптимизаций skiplist. Sorted set — это структура, где элементы имеют оценку или вес, поэтому её часто используют для рейтингов, очередей с приоритетами, лидербордов, индексов и задач, где данные нужно быстро выбирать по диапазону.
Ещё одно полезное изменение связано с rehashing — внутренней перестройкой хеш-таблиц при росте или изменении набора ключей. В реальной системе такие перестройки могут вызывать скачки задержек. Valkey 9.1 уменьшает влияние rehashing на latency, что особенно важно для нагруженных проектов: пользователю не так важно, что среднее время ответа хорошее, если периодически появляются неприятные пики.
Новые команды упрощают частые сценарии в приложениях
Valkey 9.1 добавляет несколько команд, которые закрывают типовые задачи без лишних обходных решений.
HGETDEL позволяет атомарно получить и удалить одно или несколько полей из hash. Слово «атомарно» здесь означает, что операция выполняется как единое действие: данные забираются и удаляются без промежуточного состояния, когда другой клиент мог бы вмешаться между чтением и удалением. Это полезно для очередей, временных задач и сценариев «прочитал — забрал — больше не показывай».
MSETEX позволяет установить несколько ключей с общим временем жизни одной командой. Раньше для такого сценария часто приходилось делать несколько SETEX или собирать pipeline из SET и EXPIRE. В приложениях это уменьшает количество сетевых round-trip и делает код понятнее: несколько временных значений можно записать сразу с одинаковым TTL.
CLUSTERSCAN даёт единый способ сканировать ключи по всему кластеру. Раньше клиентам нужно было обходить узлы отдельно и объединять результаты самостоятельно. Для админских инструментов, миграций, диагностики и поиска ключей это заметное упрощение: меньше логики в клиентском коде, меньше риска неправильно пройтись по кластеру.
Безопасность получила более точные права доступа и улучшения TLS
Valkey 9.1 усиливает контроль доступа на уровне отдельных баз данных. Раньше ACL-правила могли ограничивать команды и ключи, но доступ распространялся шире. Теперь администратор может привязать права пользователя к конкретным numbered databases. Для многопользовательских или многоарендных систем это важное изменение: разные приложения или команды можно лучше изолировать друг от друга.
Lua-движок вынесен в отдельный модуль. Это снижает связанность scripting-механизма с основным сервером и даёт операторам возможность отключить Lua, если он не нужен. С точки зрения безопасности это полезно: чем меньше активных возможностей в сервере, тем меньше поверхность атаки.
TLS тоже стал удобнее для эксплуатации. Valkey теперь показывает срок действия TLS-сертификатов через INFO, поддерживает автоматическую фоновую перезагрузку TLS-сертификатов и TLS-аутентификацию через SAN URI. Для команд эксплуатации это означает меньше ручной рутины и ниже риск внезапного отказа сервиса из-за просроченного сертификата.
Кроме того, в стабильный релиз 9.1.0 вошли исправления безопасности, включая CVE-2026-23479, CVE-2026-25243 и CVE-2026-23631. Эти же исправления ранее были выпущены и для поддерживаемых веток 9.0, 8.1, 8.0 и 7.2, поэтому перед обновлением стоит сверить текущую установленную версию и уже применённые патчи.
Наблюдаемость стала удобнее для продакшена
Valkey 9.1 добавляет метрики использования main thread и I/O threads. Это важнее, чем может показаться: обычная загрузка CPU не всегда честно показывает, насколько Valkey реально занят. Потоки могут находиться в busy loop и выглядеть почти как 100% CPU, даже когда фактическая нагрузка ниже. Новые метрики помогают точнее понимать состояние сервера и принимать решения по настройке.
Появился JSON-формат логов через директиву log-format json. Для небольшого проекта это может быть просто удобством, а для продакшена — существенным улучшением. JSON-логи проще отправлять в системы наблюдаемости, анализировать, фильтровать и связывать с событиями в инфраструктуре без самописных парсеров.
Улучшился и valkey-benchmark: добавлены RPS histogram, параметры --warmup и --duration. Это помогает проводить более аккуратные тесты, потому что короткий запуск без прогрева часто даёт искажённую картину. Теперь можно лучше отделить реальную устойчивую производительность от случайных всплесков в начале теста.
Обновление требует тестирования на реальной нагрузке
Valkey 9.1 выглядит сильным релизом, но переход на новую версию всё равно не стоит делать «вслепую». Особенно если Valkey используется как критичный компонент: хранит сессии, кэширует дорогие запросы, участвует в очередях, обслуживает платежный контур или поддерживает realtime-функции.
Перед обновлением стоит проверить:
- совместимость клиентских библиотек;
- поведение Lua-скриптов, если они используются;
- настройки TLS и ротации сертификатов;
- ACL-правила и доступ к numbered databases;
- нагрузочные сценарии с вашими реальными командами;
- поведение кластера, реплик и AOF/RDB-механизмов;
- метрики latency до и после обновления.
Для части проектов переход может дать экономию памяти и снижение задержек. Для других эффект будет скромнее, если узким местом является не Valkey, а сеть, приложение, база данных или неудачная схема ключей. Поэтому правильная стратегия — сначала стенд, затем canary-обновление, затем постепенное расширение на production.
Valkey 9.1 укрепляет проект как самостоятельную альтернативу Redis
Valkey 9.1 показывает, что проект развивается не только как совместимая замена, но и как самостоятельная in-memory платформа с акцентом на производительность, безопасность и эксплуатацию в больших системах. Самые заметные изменения касаются именно практики: быстрее читать короткие значения, дешевле хранить маленькие строки и sorted sets, проще обходить кластер, удобнее анализировать логи и метрики.
Для разработчиков это повод проверить новые команды HGETDEL, MSETEX и CLUSTERSCAN. Для администраторов — обратить внимание на новые метрики, JSON-логи, TLS-улучшения и модель доступа к отдельным базам. Для бизнеса — оценить, может ли обновление снизить инфраструктурные расходы без изменения архитектуры приложения..
