pg_graphql — это расширение Postgres с открытым исходным кодом, поддерживаемое Supabase, а не изобретение Aurabase. Мы создали его встроенную и добровольную интеграцию с платформой: поле для проверки каждого проекта, а не услугу, которую нужно предоставить. В этом посте подробно описана реальная архитектура, показано, как ее включить, и честно сравниваются компромиссы с Hasura и PostGraphile v5.
pg_graphqlзапускает в Postgres как расширение SQL — отдельного сервера GraphQL для развертывания не требуется, в отличие от Hasura и PostGraphile.- Функция-оболочка, предоставляемая Aurabase, —
SECURITY INVOKER: ваши политики RLS применяются автоматически, без параллельной поддержки второй системы разрешений. - Активация согласия только для каждого проекта —
aura projects graphql-enableили Studio — никогда не активируется по умолчанию ни в одном проекте. - Hasura официально переориентировала свое внимание на PromptQL и агенты искусственного интеллекта в июне 2025 года, не отказываясь от своего движка GraphQL.
- PostGraphile v5 стала общедоступной 24 марта 2026 года — это прямой и активный конкурент, а не бездействующий проект.
pg_graphql, в одном предложении
pg_graphql анализирует вашу схему SQL и генерирует схему GraphQL, соответствующую соглашению Relay — <table>Collection, edges, node, фильтрует по типу столбца, нумерацию страниц по курсору. Никакого SDL, который нужно писать или поддерживать вручную: схема GraphQL соответствует вашей схеме Postgres.
Важный для архитектуры момент: этот генератор схем живет внутри базы данных, как функция SQL, а не как соседний с ней HTTP-процесс. Aurabase закрепляет версию расширения 1.6.1 (выпущенную 7 мая 2026 г.) в своем образе Postgres — том же официальном пакете .deb, который распространяется Supabase. Он устанавливается как в общий кластер, так и на выделенные экземпляры Postgres.
Если вы работаете в Supabase, где pg_graphql уже давно включен, логика будет вам знакома. Наше подробное сравнение и наше руководство по миграции охватывают остальную часть схемы и политик RLS, которые остаются прежними.
Что изменилось в Hasura и PostGraphile
Ни один из двух исторических конкурентов «мгновенного GraphQL на Postgres» не исчез. Их позиция изменилась, и обновленная статья должна отражать это, а не ссылаться на ситуацию двухлетней давности.
В июне 2025 года Хасура опубликовал пост с явным названием «От GraphQL к PromptQL: начинается новая глава», подписанный соучредителем Танмаем Гопалом. Сообщение: компания переориентирует свою дорожную карту на PromptQL, уровень доступа к данным, предназначенный для агентов ИИ. Движок GraphQL не удален — на домашней странице Hasura он по-прежнему представлен как «проверенный в бою», — но это больше не является приоритетным сообщением.
PostGraphileсо своей стороны сделал обратное. Его версия 5, находящаяся в разработке с 2023 года в виде бета-версий, стала общедоступной 24 марта 2026 года с новым механизмом планирования запросов под названием Grafast. Это не проект, который выдыхается: последний выпуск, 5.1.4, датирован 5 августа 2026 года. Только за неделю с 16 по 22 августа 2026 года пакет npm насчитал 119 230 загрузок (реестр npm, просмотрено 23 августа 2026 г.).
Практическое следствие: настоящее свободное место — это не «GraphQL на Postgres, его никто не трогает» — это конкретный слот GraphQL с нулевой конфигурацией, активируемый одной командой, без службы для хоста. Хасура уходит от этого стратегическим выбором; PostGraphile никогда не стремился к этому, его моделью остается «библиотека Node.js для самостоятельной интеграции».
Где на самом деле превращается каждое решение
Разница, которая структурирует все остальное — эксплуатационные расходы, поверхность атаки, задержку — заключается в том, где работает движок GraphQL.
| Где он поворачивается | Расширение SQL в Postgres | Отдельный сервер GraphQL (Go) перед Postgres. | Библиотека/сервер Node.js, опережающая Postgres |
|---|---|---|---|
| Требуется развертывание | Нет — активируется флагом проекта. | Да — размещайте и масштабируйте движок Hasura | Да — разместите процесс Node или интегрируйте его со своим сервером. |
| Модель разрешений | Устаревший Postgres RLS (SECURITY INVOKER) | Собственная система разрешений Hasura, для каждой роли/таблицы. | RLS Postgres через pgSettings — тоже встроенное делегирование |
| Самоанализ по умолчанию | Неполноценный | В зависимости от конфигурации двигателя | В зависимости от конфигурации сервера |
| Позиционирование 2026 г. | Собственный вариант Postgres BaaS | Переориентация на PromptQL/IA с июня 2025 г. | GA v5 с марта 2026 г., активный проект |
| АУРАБАЗА | ХАСУРА | ПОСТГРАФИКА V5 |
Честно говоря: PostGraphile также делегирует авторизацию Postgres через pgSettings и переключение ролей — собственный RLS не является эксклюзивным для pg_graphql. Отличие заключается в том, кто размещает и настраивает этот мост: в PostGraphile это вы; в Aurabase это уже сделано.
Как Aurabase активирует pg_graphql в проекте
Активация является добровольной для каждого проекта и зарезервирована для проектов движка Postgres — проект MongoDB отклоняет запрос (GRAPHQL_UNSUPPORTED_ENGINE), поскольку pg_graphql является расширением Postgres, не имеющим эквивалента в другом движке.
Через CLI или напрямую вызвав план управления:
На стороне сервера вызов выполняет задание graphql_enable, которое поставщик выполняет в одной транзакции: установка расширения, создание функции graphql() в вашей схеме, предоставление GRANT ролям приложения. Если шаг завершается неудачей, все отменяется — оболочка никогда не устанавливается наполовину, а graphql_enabled перемещается в true только после полного успеха.
Он работает как в общем кластере Postgres, так и в выделенном экземпляре CNPG для каждого проекта — два разных образа Postgres, но один и тот же механизм расширения. В выделенных экземплярах расширение устанавливается через декларативный манифест оператора CNPG, а не через прямой SQL — недавнее исправление. Выделенный кластер работает без доступа суперпользователя приложения, и pg_graphql требует именно эту привилегию для своего CREATE EXTENSION.
В Studio тот же процесс проходит через вкладку «Конфигурация таблицы». Кнопка там активирует расширение на уровне проекта — тот же HTTP-вызов, что и выше, с опросом до конвергенции. Затем второй элемент управления устанавливает директиву @graphql для каждой таблицы, чтобы активировать или нет totalCount и поля агрегации в ее коллекции GraphQL, не выходя из редактора.
Представление одной команды: активация → потоковое задание подготовки (идемпотентное, без операций, если оно уже выполняется) → транзакция DDL (расширение, функция-оболочка, GRANT) → флаг graphql_enabled устанавливается только после полного успеха → запросы возможны через /rpc/graphql.
Устаревшая RLS, а не вторая система, которую нужно поддерживать
Функция, установленная Aurabase, — SECURITY INVOKER — поведение Postgres по умолчанию, объясненное так, чтобы будущий рефакторинг не изменил его случайно. Он запускается с привилегиями фактического вызывающего объекта (aura_anon, aura_authenticated или aura_service_role, в зависимости от утверждения JWT), поэтому ваши политики RLS применяются точно так же, как и для запроса REST.
Функция SECURITY DEFINER будет обходить весь RLS — проверено внутри: вызов graphql.resolve под подключением суперпользователя без изменения роли приложения возвращает строки всех владельцев, RLS или нет. Именно этот риск позволяет избежать перекрестного риска.
В Hasura архитектура отличается по конструкции: движок преобразует каждый запрос GraphQL в запрос SQL, ограниченный правилами разрешений, специфичными для Hasura. Эти правила определяются для каждой роли и для каждой таблицы на отдельном уровне — это параллельная система Postgres RLS, а не делегирование ей. Два места для аудита правил доступа вместо одного.
Интроспекция ({ __schema { ... } }) остается отключенной по умолчанию в каждом проекте Aurabase — положение соответствует остальной части платформы. Его можно активировать по схеме через COMMENT ON SCHEMA, если это необходимо такому инструменту, как Apollo Studio или Graphql-codegen.
Включите, а затем запросите API GraphQL.
После перехода от graphql_enabled к trueна шлюзе не появляется выделенный маршрут /graphql. Запрос проходит через общий RPC-прокси , как и любая функция Postgres, вызываемая из SDK.
Ответ соответствует спецификации GraphQL — { data, errors } — без дополнительной упаковки Aurabase: шлюз обнаруживает, что целевой RPC — это graphql, и не переобертывает его, в отличие от обычного RPC. Стандартный клиент GraphQL (Apollo, urql,graphql-request) использует выходные данные как есть.
Две настройки устанавливаются по умолчанию при активации с помощью директивы @graphql на диаграмме: max_rows: 1000 и inflect_names: true. pg_graphql по умолчанию ограничен 10 000 строк на коллекцию — без first:большая таблица может перегрузить память. inflect_names предоставляет читаемые имена типов, а не необработанный Snake_case таблиц SQL.
Чего pg_graphql не делает (пока)
Чтобы быть задокументированным, а не скрытым, в духе этого блога.
- Нет собственных подписок GraphQL. pg_graphql охватывает запросы и мутации, а не режим реального времени.
subscriptions— это ограничение самого расширения, а не упущение Aurabase. Aurabase в реальном времени существует, но через отдельный канал (postgres_changes), а не через мост подписок GraphQL. - Никаких декларативных действий в стиле Хасуры. Модель «бизнес-вебхук, подключенный к мутации GraphQL» не имеет прямого эквивалента — в Aurabase эта логика осуществляется через функцию Postgres или Edge Function, а не через специальную конфигурацию GraphQL.
- Зарезервировано для механизма Postgres. Проект MongoDB не может включить это — обходной путь не предусмотрен.
Почему активация остается добровольной, а не по умолчанию: область GRANT/Roles базы данных клиентов имеет документированную историю регрессий. Этого достаточно, чтобы оправдать тот факт, что ни одна функциональность не затрагивает его без явной проверки, проект за проектом, прежде чем рассматривать более широкий дефект.
Aurabase, Hasura или PostGraphile: в зависимости от вашего контекста
Все три варианта законны — правильный выбор зависит от того, что у вас уже есть и чего вы хотите избежать.
- pg_graphql в Aurabase — если ваша база данных и политики RLS уже находятся в Aurabase и вам нужен второй способ запроса без дополнительных служб для мониторинга.
- Hasura — если вы объединяете несколько источников данных (не только Postgres) в рамках одной схемы GraphQL или если подход PromptQL и его AI-агента соответствуют вашему плану.
- PostGraphile v5 — если вам нужен точный контроль над схемой, сгенерированной через систему плагинов, и вы уже используете сервер Node.js для ее интеграции.
Полный синтаксис запроса — фильтры по типу столбца, сортировка orderBy, нумерация страниц по курсору, мутации insertInto<Table>Collection — см. в официальной документации pg_graphql. В документации Aurabase GraphQL ниже также подробно описан полный цикл.