Агенты как новый класс нагрузки на базу: что предлагает AlloyDB и что делать остальным

Google анонсировала «PostgreSQL для агентов» в AlloyDB. Анонс продуктовый — превью, без единой строчки SQL, — но проблема, вокруг которой он построен, настоящая и обсуждается мало.

Поэтому здесь два вопроса: что именно предлагают и что делать, если вы не в Google Cloud.

Факты — из анонса Google Cloud (Raj Pai, Sujatha Mandava, 25 сентября 2026). Разбор, оценки и практическая часть мои.

Чем нагрузка от агента отличается

Начнём с проблемы, потому что она важнее конкретного продукта.

Приложение обращается к базе предсказуемо: конечный набор запросов, написанных и проверенных людьми, с понятными планами, проходящий ревью. Аналитик тоже предсказуем — он работает медленно, руками и обычно на реплике.

Агент не похож ни на то, ни на другое:

• Burst-характер. Цикл рассуждения порождает пачку запросов разом, потом тишина. Нагрузка скачет от нуля до пика и обратно.
• Запросы никто не писал. Их сгенерировала модель. План может оказаться каким угодно, LIMIT может не оказаться вовсе.
• Исследовательский характер. Агент не знает заранее, что ему нужно, и пробует — то есть делает то, чего обычное приложение не делает никогда.
• Масштабируется числом. Один агент безобиден. Сотня параллельных сессий превращается в сотню непредсказуемых клиентов.

Пустить такое на продовую базу — способ узнать, что означает Insufficient memory в самый неподходящий момент. Пустить на обычную read-реплику — почти то же самое, только сломается отчётность.

Что предлагает Google

Ответ архитектурный: эфемерные изолированные инстансы.

• инстансы PostgreSQL в песочнице поднимаются за секунды под всплеск запросов агента;
• доступ к продовым данным — только на чтение, через общий слой хранения (Colossus);
• когда агент закончил, инстансы схлопываются в ноль;
• полная изоляция от primary, standby и read-реплик;
• оплата только за активные циклы рассуждения.

Заявленные характеристики: субмиллисекундная латентность ввода-вывода, терабит в секунду агрегированной пропускной способности сканирования, поддержка более 3 млн запросов в секунду. Плюс полный движок PostgreSQL — B-tree, векторные, полнотекстовые и пространственные индексы, — федеративные запросы в BigQuery и Spark без ETL, аутентификация через IAM вместо статических паролей, VPC Service Controls и управляемое шифрование.

Оговорки, которые стоит сделать сразу

Всё это — превью. Ни одна из перечисленных возможностей не в GA. Доступ по заявке.

Цифры вендорские и без методики. «3 млн запросов в секунду» без описания запросов, данных и конфигурации — величина, с которой нечего делать. Это не обвинение в неточности, а напоминание, что сравнивать её не с чем.

В анонсе нет кода. Ни SQL, ни примеров конфигурации, ни описания API. Для технического анонса это само по себе говорит о стадии готовности.

Идея не нова, нова упаковка. Разделение вычислений и хранения — то, на чём AlloyDB и Aurora построены давно. Новое здесь — эфемерность и скейл до нуля под конкретный профиль нагрузки, и завязано это на собственное хранилище Google. Перенести подход к себе не получится: это свойство платформы, а не PostgreSQL.

Что делать, если вы не в Google Cloud

Полезная часть. Задача изоляции решаема и на обычном PostgreSQL — просто не так изящно и без скейла до нуля. Порядок действий примерно такой.

1. Отдельная реплика под агентов. Не та, с которой ходит BI, и тем более не primary. Отдельная физическая реплика — самая дешёвая и честная изоляция из доступных. В CloudNativePG это просто ещё один инстанс в кластере со своим сервисом.

2. Жёсткие лимиты на роль. Не полагайтесь на аккуратность генератора запросов:

CREATE ROLE agent_ro LOGIN;
GRANT pg_read_all_data TO agent_ro;

ALTER ROLE agent_ro SET statement_timeout          = '30s';
ALTER ROLE agent_ro SET idle_in_transaction_session_timeout = '60s';
ALTER ROLE agent_ro SET work_mem                   = '32MB';
ALTER ROLE agent_ro SET default_transaction_read_only = on;
ALTER ROLE agent_ro SET lock_timeout               = '5s';

statement_timeout здесь — главный предохранитель. Агент, сгенерировавший декартово произведение, должен упереться в таймаут, а не в память сервера.

3. Отдельный пул с ограниченным числом соединений. Свой pgbouncer (или своя секция в существующем) с небольшим pool_size: сотня параллельных агентов не должна превращаться в сотню бэкендов PostgreSQL.

4. Ограничение ресурсов на уровне контейнера. Если реплика живёт в Kubernetes — requests = limits, чтобы соседи не пострадали (см. задачу про QoS).

5. Отдельный пользователь и аудит. Агент должен ходить под своей ролью — иначе в pg_stat_activity вы не отличите его запросы от прикладных. Это же даёт возможность отобрать доступ одной командой.

6. Урезать видимость данных. Агенту почти никогда не нужна вся база. Схема с представлениями или row-level security ограничит и радиус поражения при ошибке, и объём утечки при компрометации.

Это не даст ни секундного подъёма песочницы, ни оплаты по факту. Но закрывает главное — чтобы эксперименты агента не влияли на прод.

Куда смотреть дальше

Направление в целом верное: агенты действительно новый профиль нагрузки, и ответ «дайте им отдельные эфемерные вычисления поверх тех же данных» выглядит здраво. Похожие решения почти наверняка появятся у других облаков и, возможно, в открытых проектах — разделение вычислений и хранения перестало быть экзотикой.

Практический же вывод на сегодня скромнее: посмотрите, куда сейчас ходят ваши агенты. Если в ту же базу, что и приложение, под той же ролью и без statement_timeout — это стоит поправить на этой неделе, не дожидаясь ничьих превью.