К 2028 году средняя компания из Fortune 500 может использовать больше 150 000 AI-агентов, и многим из них понадобится собственное состояние, память и доступ к данным. Поэтому AI-агенты для баз данных превращаются из красивой демо-идеи в проблему для DBA, архитекторов и команд платформенной инженерии: кто будет выдавать им базы, ограничивать ресурсы и разбирать последствия ошибок?
О таком сценарии пишет The New Stack в спонсорском материале Yugabyte. Прогноз, на который ссылается издание, звучит резко: у средней глобальной компании Fortune 500 число AI-агентов может вырасти с менее чем 15 в 2025 году до более чем 150 000 в 2028-м. При этом только 13% организаций считают, что у них уже есть подходящее управление для такого зоопарка автономных систем. DBA в этой картине не исчезает, но перестает быть человеком, который руками чинит каждую медленную выборку и лично сопровождает каждую миграцию.
Логика сдвига проста. Классический администратор баз данных годами отвечал за доступность, производительность, безопасность и стоимость: выделить емкость, найти проблемный запрос, провести миграцию, откатить неудачный релиз, объяснить бизнесу, почему отчет опять строится как будто через дальнюю орбиту. Автоматизация в этой области давно не новость, но агенты обещают другой уровень: не просто выполнить заранее прописанный скрипт, а посмотреть на метрики, выбрать действие, применить инструмент и проверить, стало ли лучше.
Это не значит, что компаниям предлагают выдать роботам полный доступ к продакшену и уйти пить кофе. Наоборот, работа человека смещается выше: DBA должен определить, какие операции агент может выполнять сам, где нужен approve, какие лимиты на CPU и память допустимы, какие действия логируются, а какие вообще запрещены. Если раньше администратор обслуживал конкретную базу, то теперь он проектирует правила для целого флота баз, которые появляются, простаивают, масштабируются и удаляются по мере жизни агентов.
Yugabyte продвигает под этот сценарий YugabyteDB AMP — Agentic Multitenant PostgreSQL. Идея продукта в том, чтобы не заводить отдельную тяжелую инфраструктуру под каждый небольшой агентский workload, а размещать сотни небольших Postgres-нагрузок на общей распределенной основе, сохраняя изоляцию между базами. Жизненный цикл — provisioning, branching, scaling, migration и teardown — можно отдавать агентам через MCP. У Yugabyte также есть специализированные агенты для настройки, миграций, performance tuning и интеграций.
Экономика здесь не менее важна, чем эксплуатация. Агентские нагрузки часто ведут себя не как привычные приложения: быстро появляются, долго бездействуют, затем внезапно создают всплеск активности. Если под каждый эксперимент держать постоянно выделенные ресурсы, счет за инфраструктуру начнет выглядеть как тест на стрессоустойчивость финансового директора. Поэтому AMP делает ставку на serverless multitenancy, scale-to-zero и оплату по CPU-минутам: простаивающий агент не должен есть compute, а отдельный слишком активный агент не должен забирать ресурсы у соседей.
Для разработчиков это означает более короткий путь от эксперимента к production, но и более жесткие требования к дисциплине. Агент, который вчера был внутренним прототипом для поддержки саппорта, завтра может стать частью критического процесса. Если для экспериментов и серьезных нагрузок используются разные платформы, команда получает миграционную яму: данные надо переносить, поведение перепроверять, интеграции чинить. Yugabyte предлагает начинать с serverless Postgres, а затем переводить выросшие нагрузки на распределенную PostgreSQL-совместимую YugabyteDB без переписывания приложения и переезда на другую платформу.
Отдельный слой — память и контекст. Агентам мало просто хранить таблицы: им нужно помнить предыдущие действия, делиться знаниями с другими агентами, оставлять следы решений и давать людям возможность проверить, почему система поступила именно так. Для этого в стеке Yugabyte фигурирует Meko — context engine для multi-agent AI-систем. Он должен хранить persistent memory, shared knowledge, decision traces и auditability, чтобы агенты не жили каждый в своем изолированном пузыре и не переоткрывали одно и то же по кругу.
Для русскоязычных IT-команд главный вывод без романтики: AI-агенты для баз данных — это не только про удобные ассистенты для DBA. Это вопрос governance, стоимости и архитектуры данных. Кто имеет право создать базу? Кто видит персональные данные? Что происходит, если агент ошибся в миграции? Как откатить действие, которое выполнила цепочка агентов? На эти вопросы придется отвечать раньше, чем в компании появятся десятки тысяч автономных процессов.
Сам прогноз про 150 000 агентов к 2028 году может оказаться завышенным или, наоборот, слишком осторожным — рынок AI уже не раз показывал, что линейные ожидания тут плохо работают. Но направление выглядит убедительно: DBA будущего будет меньше администрировать отдельные базы руками и больше управлять политиками, лимитами, аудитом и автономными системами, которые делают эту работу за него. Вопрос не в том, заменят ли AI-агенты для баз данных администраторов, а в том, какие команды первыми научатся управлять ими без хаоса в данных и счетах за инфраструктуру.