ИИ‑агенты генерируют непривычные для классических СУБД нагрузки: сотни итераций, выбор «лучшего ответа» и долгоживущие состояния. Глава Percona объяснил, почему нынешние базы справляются «как получится» — и что стоит предусмотреть командам уже сейчас.
ИИ‑агенты быстро превращаются из «игрушки для демо» в рабочий инструмент: они пишут код, собирают отчёты, запускают цепочки задач и постоянно сохраняют промежуточные результаты. И вот здесь выясняется неприятное: привычные базы данных были спроектированы под другие сценарии.
Что произошло
На мероприятии Percona Live в Амстердаме генеральный директор Percona Питер Фаркаш заявил, что «лучшей» базы данных именно для агентных (agentic) сценариев на рынке пока нет. По его словам, индустрия СУБД оказалась не готова к тому, как именно агенты используют хранилища и как быстро меняются требования.
Percona работает с популярными open-source стеками и экосистемами: MySQL, PostgreSQL, MongoDB, а также технологиями уровня Redis/Valkey. Но даже при таком наборе вариантов, как подчёркивает Фаркаш, компании сегодня выбирают скорее «то, что есть», а не «то, что идеально подходит».
Почему агентам тесно в привычных СУБД
Классические приложения часто пишут данные по понятной схеме: транзакции, отчёты, аналитика. У ИИ‑агентов паттерн другой: они могут пробовать десятки и сотни вариантов, сохранять черновики, промежуточные гипотезы, результаты инструментов и «контекст» длинных сессий. Фаркаш приводит пример итеративной работы, когда агент делает множество попыток (условно — 150 вариантов), а затем человек или другой процесс выбирает лучший.
Такая модель поведения меняет профиль нагрузки:
- много мелких записей и временных данных, которые быстро устаревают;
- частые перезаписи и повторные вычисления, потому что агент «учится на ходу»;
- смешение типов данных: структурированные факты, embeddings, журналы действий, результаты инструментов, документы;
- длинные цепочки, где важно сохранять состояние и объяснимость, а не только финальный ответ.
Что это значит для бизнеса и разработки
Главная мысль здесь практичная: если вы строите продукт с агентами, не стоит рассчитывать, что одна выбранная СУБД «закроет всё» на годы вперёд. Рынок ещё не успел выработать стандартную архитектуру под такие нагрузки — и, по мнению Фаркаша, сначала должны стабилизироваться сами сценарии применения.
Параллельно компании всё ещё определяются, где именно ИИ должен жить в их стеке:
- запускать модели у себя или опираться на облачные сервисы;
- нужен ли в каждом кейсе большой LLM или достаточно более компактной модели;
- где хранить долговременную память агента и как управлять её ростом.
Как подготовиться уже сейчас (без «переписывания всего»)
Даже если «идеальной» базы под агентов пока нет, команды могут снизить риски заранее — за счёт архитектурной гибкости:
- разделяйте хранилища по назначению: оперативные данные продукта — отдельно, журналы действий агента и временные артефакты — отдельно;
- планируйте жизненный цикл данных: что хранится неделями, что — часами, что можно удалять автоматически;
- закладывайте переносимость: абстракции доступа к данным и понятные контракты помогут сменить технологию без «большого взрыва»;
- меряйте итеративность: сколько попыток делает агент, сколько данных оставляет после себя, как растёт стоимость хранения и индексации.
Суть новости не в том, что «всё плохо», а в том, что агентные нагрузки заставляют пересматривать привычные решения. И, похоже, ближайшие годы на рынке будут появляться новые подходы к хранению состояния агентов — так же, как когда-то появились отдельные инструменты под логи, аналитические витрины и потоковую обработку.
Источник: The Register
