Redis и цена амбиций

Статья Чарльза Лайфера 2026 года, написанная под впечатлением от PR'а от antirez'а с добавлением типа array в Redis. Обоснование в PR - хэшам для поиска нужен ключ, списки прячут середину, стримы работают только на добавление - вполне годится как локальный аргумент, но Лайфер смотрит шире и спрашивает: "На дворе 2026 год, Redis переживает кризис, и при этом перед нами лежит огромный PR с добавлением нового типа array. Что вообще происходит?"

Ответ вынесен в заголовок - амбиции. Redis начинался как сервер структур данных в оперативной памяти с чётко очерченными границами, но постепенно обрастал возможностями, пытаясь стать всем для всех, и растерял то самое свойство, которое делало его незаменимым. Текущий кризис - прямое следствие двух десятилетий попыток казаться чем-то большим.

Картина кризиса 2026 года

Лайфер перечисляет недавние очаги напряжения:

Лицензирование. В 2024 году Redis Inc отказалась от BSD, сообщество взбунтовалось, и компания пошла на стратегическое отступление к тройному лицензированию с AGPLv3 как единственным вариантом от OSI. AGPL позволяет Redis Inc говорить об "open source", но AGPL не равна BSD в практическом смысле.
Предыстория с Garantia Data. Венчурная компания, стоящая за Redis, начиналась как Garantia Data, сервис хостинга NoSQL; затем занялась хостингом Redis, провела ребрендинг, наняла antirez'а для легитимации и со временем забрала себе товарный знак - подготовив почву для отзыва лицензии в 2024 году.
Раздувание и привязка к вендору. Набор возможностей рос и рос, вобрав в себя экзотические структуры данных, сложные системы с состоянием (streams) и полупроприетарные модули.
Дрейф позиционирования. Главная страница Redis в 2026 году называет его The Real-Time Context Engine for AI Apps, соседствуя с кнопками "Try Redis for Free" и корпоративным "Get a Demo".
Линия "мы тоже настоящая web-scale база данных". Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash®.
RESP3. Лайфер видит в нём классический бруксовский эффект второй системы - разрушение принципа "запрос/ответ", лежавшего в основе RESP2.
Клиентское кэширование как часть протокола. Доведение до абсурда: Redis'у (который изначально сам был кэшем) теперь нужен новый протокол, чтобы поддерживать кэширование ещё и на стороне клиента.

Что Redis сделал идеально в 2011 году

По мысли Лайфера, амбиции лишили Redis трёх вещей, которые делали его незаменимым:

Сетевой протокол. Достаточно простой, чтобы разобрать и реализовать за час, и достаточно выразительный, чтобы передавать реальные типы данных. Писать клиент для Redis необычайно приятно. Самый популярный пост самого Лайфера - написание простого сервера Redis на Python - появился именно потому, что протокол буквально подталкивает к такому эксперименту.
Однопоточный, событийно-ориентированный, in-memory. Эти три свойства неразрывны: один поток делает операции полностью атомарными (никаких блокировок и рассуждений о конкуренции). Однопоточность требует неблокирующего ввода-вывода. Работа в оперативной памяти обеспечивает скорость, достаточную для обслуживания множества клиентов одним потоком. Уберите любое из этих звеньев - и архитектура рухнет; вместе же они образуют стройное целое.
Структуры данных. Связный список, хэш-таблица, множество, сортированное множество, строки. Каждая закрывала реальный сценарий (очередь, структурированная запись, дедупликация, лидерборд, кэшированное значение). Примитивы были подобраны со вкусом. Этой горстки хватало.

Траектория "амбиций"

Лайфер прослеживает историю добавления возможностей и замечает закономерность: каждое крупное нововведение точно совпадает с тем, чем в тот момент восторгался HN:

MongoDB -> Redis как документная база данных
ElasticSearch -> Redis как поисковый движок
Графовые базы данных -> RedisGraph... который затем закрыли
Kafka -> Streams
ZooKeeper / строгая согласованность -> Redis-Raft
InfluxDB -> Временные ряды
ИИ -> Векторные множества

Отсюда вытекают два режима отказа:

Забывание того, почему Redis победил. Простота, ортогональность, концептуальная целостность. Наросшие со временем модули этими качествами не обладают.
Сырые альтернативы проигрывают специализированным решениям. Любой, кому всерьёз нужны полнотекстовый поиск, потоковая передача событий, строгая согласованность, временные ряды или векторное хранилище, выберет специализированную систему, а не модуль для Redis, наследующий все компромиссы Redis'а в плане отказоустойчивости, персистентности и неудобств протокола.

Разбор раннего Redis-Raft (1b3fbf6) от Aphyr'а остаётся наглядным примером: "двадцать одна проблема, включая длительную недоступность в здоровых кластерах, восемь падений, три случая чтения устаревших данных... практически непригодно к использованию".

Показательная история с Disque

Лайфер вспоминает собственный прогноз 2015 года. Когда antirez анонсировал Disque (брокер сообщений в стиле Redis), он отметил: "Disque проектировался слегка в режиме космонавта - не ради решения моей собственной практической задачи, а скорее как реакция на то, как люди использовали Redis и другие системы в роли очередей сообщений".

Лайфер расценил это как предвестник заброшенности проекта и тогда же объяснил, почему им никто не станет пользоваться: в 2015 году уже существовало множество зрелых брокеров сообщений; люди использовали Redis как брокер просто потому, что уже использовали Redis; потребность была не в новом брокере, а в том, чтобы Redis оставался Redis'ом. Disque неверно оценил собственный спрос.

Прогноз оправдался - Disque превратился в заброшенный проект вскоре после анонса (8 тысяч звёзд и никакого движения), а его переписывание в виде модуля для Redis тоже заглохло. "Режим космонавта" - паттерн, сформулированный Лайфером: возможности, которые разрабатываются как личный вызов или упражнение в обучении, без реального сценария использования, способного вытянуть длинный хвост сложных проблем.

Куда ушла энергия

Лайфер прямо подчёркивает, что это не личная критика antirez'а - он "безгранично уважает его талант и вкус". Главные движущие силы здесь структурные:

Стремление разработчиков решать интересные задачи.
Амбиция стать всем для всех.
Амбиция владельцев Redis'а выжать максимум выручки до того, как AWS и GCP (руками Valkey) окончательно их вытеснят.

Valkey как вердикт

Появление и признание Valkey - ответ рынка. Вместо погони за пунктами в списке возможностей (см. страницу сравнения Redis и Valkey), Valkey вложился в негламурную работу - многопоточную производительность, эффективность работы с памятью, надёжность и пропускную способность кластера. Бенчмарки бьют ровно по "80% пользователей Redis, которым нужно лишь то, что Redis предлагал в 2011 году". Финальный аккорд Лайфера: "В мире Valkey нет потребности в новом типе array".

Страница valkey-secret-life-of-data как раз описывает эту негламурную работу изнутри: никаких новых типов данных, только пороги кодирования и сэкономленные ноды кластера в счёте за инфраструктуру.

Место в общей картине

no-silver-bullet-llms / no-silver-bullet - сущностная и привнесённая сложность по Бруксу. Поверхность привнесённой сложности в Redis безгранично разрасталась, в то время как сущностная сложность (кэширование данных, базовые примитивы конкурентности для веб-приложений) никуда не сдвинулась. Накопление надстроек идёт вразрез с Бруксом.
ceo-ai-psychosis / ai-great-leap-forward - производство возможностей ради метрик в другом контексте. Главная страница Redis 2026 года, именующая его The Real-Time Context Engine for AI Apps, - это tokenmaxxing в категории баз данных.
duckdb-quack-protocol - противоположная траектория в мире баз данных: изначально внутрипроцессная система аккуратно добавляет один сетевой протокол, потому что зоопарк обходных путей стал больше самого протокола. Опубликованное командой DuckDB обоснование ("нам нужна свобода контроля над форматом; мы выбрали HTTP ради экосистемы") показывает, как выглядит взвешенное проектирование протокола при честных ограничениях. У RESP3 таких ограничений не было.
best-polished-version-strategy - Valkey выступает "лучшей отшлифованной версией" Redis'а как кэша, и это работает именно потому, что исходный инструмент ухудшился достаточно сильно (драма с лицензиями, RESP3, ИИ-позиционирование), чтобы перевесить издержки перехода. Та же динамика, что и у Linear против Jira.
supply-chain-security - отзыв лицензии в истории Redis представляет собой ещё одну форму кризиса доверия в цепочке поставок; захват товарного знака компанией Garantia / Redis Inc - структурный механизм, на который теперь ссылаются многие страницы вики, не называя сам Redis. Эта страница конкретизирует каноническую отсылку.

Цитаты

The problem is when the ambition leads you to lose sight of what made you successful in the first place.

People use Redis as a message broker specifically because they don't want to use something else.

Связанные страницы

antirez - страница Сальваторе Санфилиппо; того самого человека, чьи решения по функциональности этот анализ трактует как раздувание системы из-за амбиций.
control-the-ideas-not-the-code - собственный аргумент antirez'а от июля 2026 года о том, что опытные программисты должны удерживать общее архитектурное видение и перестать построчно вычитывать код от LLM; он воспринимает рядовые PR'ы со структурами данных как поддержание кода со вкусом, а не как расползание функциональности.