CobbleDB Perplexity снизила медианную задержку пакетного чтения в поисковой инфраструктуре с 31,4 мс до 5,60 мс. Компания заменила часть DynamoDB собственным key-value-хранилищем, а AI-агентов пустила в разработку, но не к управлению продакшеном. Для команд, которые строят AI-поиск или RAG-системы на растущих облачных счетах, это неприятно практичный сигнал: иногда «купить готовое» перестает быть дешевле и быстрее.
Как пишет The New Stack, Perplexity решила переписать слой хранения после того, как DynamoDB перестала устраивать компанию по двум причинам: рост стоимости при увеличении индекса и запросов, а также недостаточный контроль над тем, как обслуживаются чтения. Речь не о замене всей базы данных в духе «мы теперь сами Amazon», а о более узкой вещи: горячем хранилище для подготовленных записей веб-страниц, которые нужны поиску перед тем, как ответ попадет к модели.
Новая система получила название CobbleDB. Она хранит данные в формате ключ-значение: ключами выступают хешированные URL, значениями — подготовленные представления страниц, включая фрагменты текста и embeddings. По данным Perplexity, поисковый запрос может требовать чтения пакетов примерно по 10-15 ключей, средний размер элемента — около 50 КБ. Это не классическая банковская транзакционная нагрузка, где важны строгая согласованность и немедленная видимость записи. Это путь чтения, где главное — быстро достать пачку заранее подготовленных данных и не дать одному медленному узлу испортить весь ответ.
Производственные замеры у Perplexity выглядят заметно. После миграции медианная задержка batch-read упала с 31,4 мс до 5,60 мс. На p90 показатель снизился с 56,7 мс до 9,77 мс, на p99 — со 123 мс до 24,2 мс. Компания также говорит о нагрузке примерно 200 тыс. запросов в секунду для обеих систем и о нагрузочных тестах до 500 тыс. rps без деградации. Важная оговорка: это сравнение «до и после» на живом трафике в разные моменты, а не лабораторный прогон одних и тех же запросов. Для инженерного блога честная оговорка; для маркетинговой страницы — почти подвиг.
Архитектура разделена на три роли. CobbleDB отвечает за быстрый read path. Pillar хранит durable-состояние документов и решения о публикации версий. Lorry превращает обновления в пакетные поставки для партиций. Такой разнос нужен, чтобы переиндексация, смена chunking-логики или обновление embedding-модели не дрались за ресурсы с живыми поисковыми запросами. Раньше, судя по описанию компании, обработка документов была сильнее связана с базой, из которой потом читали пользователи. На масштабе AI-поиска это быстро превращается в дорогую очередь из компромиссов.
Внутри CobbleDB используется RocksDB, локальные NVMe-диски, кеширование в памяти и репликация: у каждой партиции по три реплики на разных узлах. Роутер группирует ключи по партициям, выполняет чтения параллельно и предпочитает реплику в той же зоне доступности. Если одна реплика отвечает медленно, запрос может быть продублирован на другую. Это называется hedged read: лишняя работа для инфраструктуры, зато меньше шансов, что один «сонный» узел растянет хвостовую задержку. Цена такого дизайна понятна — система не претендует на универсальность и не пытается быть базой для всего подряд.
Экономика тоже стала аргументом. Perplexity утверждает, что CobbleDB минимум на 20% дешевле DynamoDB по внутренней модели затрат. Оценка учитывает хранение, чтение и запись, но не включает возможную экономию на бэкапах за счет сжатия. Конкретных абсолютных сумм компания не раскрывает, и это правильно не додумывать за нее. Но сам паттерн знаком многим быстрорастущим сервисам: сначала managed-сервис экономит время команды, потом usage-based-модель начинает выставлять счет за каждую архитектурную привычку.
Отдельная часть истории — AI-агенты. По словам Perplexity, ядро инфраструктуры CobbleDB написали два инженера при поддержке сотен внутренних coding agents примерно за два месяца; объем ядра оценивается примерно в 40 тыс. строк Rust. Агенты помогали разбирать существующие обсуждения, pull request, владельцев компонентов, риски и следующие действия, а также брали на себя рутинную проверку и сопровождение изменений. Но архитектуру, ревью критичных изменений и разрешение операций в продакшене оставили людям. То есть агенты были усилителем команды, а не ночным дежурным с правами на кластер. И это, пожалуй, самая взрослая часть эксперимента.
Для разработчиков вывод не в том, что всем пора писать свою базу данных. Скорее наоборот: CobbleDB Perplexity показывает, насколько узкой должна быть задача, чтобы самописная инфраструктура имела смысл. Нужна предсказуемая нагрузка, понятный формат данных, терпимость к асинхронному обновлению, сильная команда и очень дорогой bottleneck. Если у вас обычный CRUD, DynamoDB, Postgres или другой managed-вариант по-прежнему, скорее всего, дешевле самоуверенности. Если у вас AI-поиск с сотнями тысяч чтений в секунду и большими подготовленными payload, разговор уже другой.
История Perplexity хорошо ложится в более широкий тренд: AI-компании начинают переписывать не только интерфейсы и модели, но и скучные слои инфраструктуры — crawling, indexing, ranking, storage. Чем дороже становится inference и чем сильнее сервис зависит от latency, тем меньше терпения к универсальным абстракциям. Вопрос теперь не «заменят ли AI-агенты инженеров», а кто быстрее научится давать им тяжелую работу, не отдавая им ключи от продакшена.