PostgreSQL готовят к эпохе AI-агентов

AI-агенту мало уметь писать код. В какой-то момент ему понадобится доступ к данным приложения - прочитать таблицу, найти нужную запись, сохранить результат или проверить, почему запрос работает медленно.

И тут начинается неприятная часть.

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

Именно на эту проблему 28 сентября 2026 года решила нацелиться компания pgEdge. Она представила Starfleet - платформу вокруг PostgreSQL, которая должна сократить путь от AI-прототипа до production без необходимости потом полностью переделывать инфраструктуру.

И здесь интересен не столько очередной AI-сервис, сколько сама идея: PostgreSQL постепенно становится частью инфраструктуры, рассчитанной на работу автономных программных агентов.

Агенту нужен не просто доступ к базе

Обычное приложение заранее знает, что ему нужно сделать.

Например, интернет-магазин получает заказ, записывает его в PostgreSQL и затем обращается к нескольким заранее определённым таблицам.

AI-агент работает иначе. Он может сам определить, какие данные ему нужны, сформировать запрос, проверить результат и использовать его для следующего действия.

Для разработчика это меняет привычную картину.

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

В Starfleet появился встроенный MCP-сервер. Он позволяет подключать к базе инструменты вроде Claude Code, Cursor и Replit. При этом компания добавила собственные механизмы ограничения доступа, включая SafeSession, который позволяет работать с базой в режиме только для чтения.

Это важная деталь.

MCP сам по себе не превращает базу данных в безопасную среду для автономного агента. Он всего лишь создаёт стандартизированный способ взаимодействия. В production всё равно приходится решать вопрос разрешений.

Поэтому вокруг MCP в Starfleet появляется отдельный слой управления.

Самая интересная часть - ветки базы

Есть ещё одна проблема, которая становится заметнее именно с агентами.

Представим команду, где несколько AI-агентов одновременно меняют приложение. Один пишет миграции, второй тестирует новую функцию, третий пытается оптимизировать запросы.

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

Можно создавать отдельные базы вручную, но это быстро превращается в инфраструктурную работу.

В Starfleet для этого используются copy-on-write database branches. Фактически можно создавать отдельные ветки PostgreSQL для экспериментов, разработки, тестирования и staging, не копируя каждый раз весь набор данных обычным способом.

Для AI-агентов это особенно интересно.

Получается модель, похожая на Git:

агент получает собственную среду → экспериментирует → проверяет результат → изменения можно оценить отдельно от основной базы.

Причём pgEdge подчёркивает, что для этого не заменяет PostgreSQL собственной системой хранения. Starfleet использует PostgreSQL и реализует branching поверх него.

Именно здесь идея выглядит практичнее многих разговоров про «AI-native базы данных».

Не обязательно создавать новую базу данных с нуля. Иногда достаточно изменить то, как разработчики и агенты с ней работают.

PostgreSQL становится местом не только для SQL

Ещё одна часть Starfleet связана с RAG.

Сегодня типичный AI-проект может выглядеть примерно так: PostgreSQL хранит основные данные приложения, отдельно работает векторная база, ещё где-то находится поисковый индекс, а между всеми компонентами появляется дополнительный слой API.

Для небольшого прототипа это терпимо.

Но чем больше компонентов появляется вокруг модели, тем больше вещей приходится поддерживать.

pgEdge предлагает другой подход: использовать PostgreSQL как центральное место для обычных данных, векторов и поиска. В платформе используются pgvector и встроенный RAG-сервер, а также поддерживается гибридный поиск.

Получается довольно показательная схема:

PostgreSQL → данные → поиск → RAG → AI-агент.

Не всё обязательно выносить в отдельную инфраструктуру.

Это не означает, что отдельные векторные или поисковые системы больше не нужны. Для больших и специфических нагрузок они по-прежнему могут иметь смысл. Но для многих AI-приложений разработчик получает возможность начать с гораздо более простой архитектуры.

Главная проблема появляется после прототипа

Именно здесь и находится главный смысл Starfleet.

Создать AI-прототип сегодня сравнительно легко. Можно взять готовую модель, подключить базу, добавить RAG и получить работающую демонстрацию за короткое время.

Проблемы начинаются, когда этим нужно пользоваться настоящим клиентам.

Кто имеет доступ к базе?

Можно ли агенту менять данные?

Что произойдёт, если он отправит неправильный запрос?

Где физически находятся данные?

Как сделать резервное копирование?

Как перейти от одной базы к нескольким регионам?

Что делать с требованиями компании, если данные нельзя отдавать в чужое облако?

В пресс-релизе pgEdge приводит данные IDC и Lenovo, согласно которым только 46% общих и agentic AI-прототипов доходят до production. Компания связывает часть проблемы с тем, что инфраструктура, удобная для экспериментов, не всегда соответствует требованиям production-систем.

Это как раз объясняет, зачем Starfleet пытается объединить две вещи, которые обычно существуют отдельно.

С одной стороны - удобство разработчика.

С другой - контроль инфраструктуры.

От облака до собственного сервера

При этом Starfleet не ограничивается вариантом «запустите всё у pgEdge».

Платформу можно использовать как управляемую услугу, развернуть в собственном облаке или использовать self-hosted вариант, включая on-premises и изолированные среды. pgEdge отдельно заявляет поддержку air-gapped-развёртываний.

Это особенно важно для компаний, которым недостаточно просто получить AI-функцию.

Например, разработчик может начать с небольшой базы в облаке, а затем столкнуться с требованиями заказчика, при которых данные должны находиться внутри собственной инфраструктуры.

Вместо миграции на совершенно другую технологию предполагается сохранить тот же PostgreSQL-стек и изменить способ его размещения.

По заявлению pgEdge, Starfleet работает на базе стандартного open source PostgreSQL, а не на отдельной СУБД.

Это не новый PostgreSQL

И здесь стоит аккуратно относиться к формулировке «PostgreSQL готовят к AI-агентам».

Сам PostgreSQL Community не превращается в специальную AI-базу.

Starfleet - продукт pgEdge, построенный вокруг PostgreSQL. В него добавляются MCP, RAG, branching, инструменты управления и другие компоненты, необходимые для AI-приложений.

То есть речь скорее о новом способе использовать PostgreSQL, чем о радикальном изменении самой СУБД.

И это, пожалуй, самая интересная часть истории.

AI-агенты постепенно заставляют разработчиков пересматривать не только модели, промпты и инструменты. Меняется инфраструктура, к которой эти агенты получают доступ.

Раньше база данных была местом, куда приложение отправляло заранее написанные запросы.

Теперь появляется сценарий, где программа сама решает, какие данные ей понадобятся и какие действия выполнить.

Отсюда возникают совершенно другие требования к базе.

Нужен контролируемый доступ. Нужны изолированные среды для экспериментов. Нужен поиск по собственным данным. Нужна возможность быстро масштабироваться. И желательно, чтобы после успешного эксперимента не приходилось выбрасывать всю созданную инфраструктуру.

Starfleet пытается собрать эти требования вокруг уже знакомого PostgreSQL.

Пока это предложение конкретного поставщика, а не изменение самого PostgreSQL. Но направление показательное: эпоха AI-агентов постепенно заставляет базу данных становиться не просто хранилищем, а частью среды, в которой автономные программы могут безопасно экспериментировать, искать данные и выполнять действия.

А значит, вопрос для разработчика постепенно меняется.

Уже недостаточно спросить: «Как подключить AI-агента к PostgreSQL?»

В production гораздо важнее другой вопрос:

«Что произойдёт с моей базой после того, как агент получит к ней доступ?»