Три цифровых стартапа из AI-сектора — Huntr, Modelence и Tavily — построили свои продукты на MongoDB Atlas вместо классической связки из реляционной базы, отдельного поиска и отдельного векторного хранилища. Для тех, кто делает агентные ИИ-системы, это не спор о вкусе, а довольно приземленный вопрос: сколько времени команда тратит на миграции, синхронизацию данных и борьбу с инфраструктурой, которая плохо переносит постоянные изменения.
Как пишет VentureBeat, все три компании пришли к одному и тому же выводу: в агентном софте данные меняются слишком быстро, чтобы держаться за жесткие схемы как за священную корову. Важно и другое: речь идет не о лабораторных экспериментах, а о продакшене с реальными пользователями, API-ключами, поиском в реальном времени и растущей нагрузкой. При этом сам материал опубликован при поддержке MongoDB, так что восторг источника лучше читать с поправкой на жанр. Но сами кейсы от этого менее показательными не становятся.
Где реляционные базы начинают тормозить
Главный тезис материала сводится к понятию architectural drag — архитектурного трения. На практике это разрыв между тем, что уже умеют генерировать AI-модели и агенты, и тем, что может надежно переварить привычная backend-инфраструктура. У агентных систем требования к слою данных обычно неприятно комбинируются: переменная структура документов, векторные эмбеддинги, поиск по смыслу и по ключевым словам, retrieval в реальном времени, многопользовательская изоляция и масштабирование без ручного вмешательства после каждого нового сценария. Если поверх этого лежит фиксированная схема, любая новая форма данных быстро превращается в новый раунд миграций, а если рядом стоит еще и отдельная vector DB, появляются задержки и накладные расходы на синхронизацию.
Modelence, по версии VentureBeat, увидела эту проблему одной из первых. Компания делает AI app builder и open source-фреймворк для agent-native-разработки: идея в том, чтобы собирать и выкатывать готовые веб-приложения с API и базой данных за минуты. Сооснователь и CEO Aram Shatakhtsyan объясняет выбор просто: чем меньше платформ надо склеивать между собой, тем меньше точек, где агент ошибется. У Modelence document model MongoDB сочетается с типизированным слоем поверх данных. Это важная деталь: компания не противопоставляет гибкость и типизацию, а держит обе вещи одновременно. По словам Shatakhtsyan, связка с TypeScript дала единый источник правды для логики приложения и базы, а итогом стали более быстрый переход от планирования к рабочей фиче и меньше регрессий. На этом фоне стартап привлек $3 млн seed-инвестиций и вывел на рынок AI-native-конструктор приложений.
Кейс Tavily показывает другую сторону той же проблемы. Это search API для AI-агентов, который должен подмешивать в ответы модели актуальные данные из веба, а не только содержимое обучающей выборки. На таком продукте быстро выясняется, что «данные» — это не только сами документы, но и их жизненный цикл: когда URL был получен, насколько он устарел, какие сигналы свежести есть у источника, насколько материал популярен, как расходуется тариф и к какому региону относится клиент. Data Team Lead Tomer Weiss говорит, что схема этих записей менялась по мере появления новых метрик и фич, и именно гибкая модель позволяла делать это без миграций на каждом шаге. Для масштаба с миллионами API-ключей Tavily рано развела нагрузки по кластерам: один кластер под аккаунты, аутентификацию и usage writes, второй — шардированный кластер под состояние документов, где ось масштабирования строится вокруг URL, а не пользователей. Это уже не разговор про моду на NoSQL, а про довольно трезвую инженерную декомпозицию.
Что это значит для команд, которые строят AI-продукты
История Huntr особенно понятна небольшим командам. Платформа для создания и адаптации резюме работает более чем с 500 тыс. соискателей из 190 стран, а инженерная команда при этом состоит из трех человек. Для такого состава лишняя инфраструктурная сложность быстро становится роскошью. Senior software engineer Trevor McCann описывает задачу без романтики: карьерные данные пользователя по природе неровные, глубоко вложенные и постоянно меняются от кандидата к кандидату. В такой модели неудобно притворяться, что у всех одно и то же резюме в одной и той же схеме. Huntr хранит эти данные в MongoDB Atlas, использует MongoDB Search для обычного поиска и Vector Search для Job Tailoring — функции, которая сопоставляет профиль кандидата и описание вакансии, а затем помогает сгенерировать релевантное резюме. Для маленькой команды выигрыш здесь очевиден: меньше отдельных сервисов, меньше интеграционного клея, меньше времени на обслуживание стека.
Из этих кейсов складывается понятный тренд. Агентные ИИ-системы плохо уживаются с архитектурой, где каждый новый тип данных надо согласовывать с DBA, а каждую AI-функцию прикручивать через еще один специализированный сервис. Не потому, что SQL внезапно «умер» или документные базы подходят всем подряд. А потому, что для части AI-продуктов цена жесткости стала слишком высокой. Если команда строит workflow, где агент постоянно создает новые сущности, хранит промежуточные состояния, работает с эмбеддингами и должен быстро дотягиваться до актуального контекста, то единая платформа данных действительно выглядит прагматичнее, чем конструктор из трех-четырех отдельных систем.
Для русскоязычной IT-аудитории здесь важен не рекламный вывод про конкретного вендора, а сам инженерный сдвиг. Побеждают не те, кто громче всех добавил слово AI на лендинг, а те, кто убрал лишнее трение между моделью, данными и продакшеном. Вопрос теперь звучит так: останутся ли агентные ИИ-системы нишей для стартапов с гибким стеком или заставят и более консервативные компании пересмотреть привычную любовь к жестким схемам, отдельным индексам и бесконечным миграциям. Первоисточник с цитатами компаний — .