PostgREST против Hasura против пользовательского API

За вопросом «PostgREST или Hasura или собственный API» скрывается более полезный вопрос: кто пишет вашу бизнес-логику, каким инструментом и кто использует этот код в продакшене? Три архитектуры реагируют по-разному, и эта разница структурирует все остальное — безопасность, скорость внедрения, технический долг в долгосрочной перспективе.

Ни одна из трех колонок не является строго лучшей: каждая переносит работу в другое место. PostgREST переносит его в SQL, Hasura — в конфигурацию и веб-перехватчики, а специальный API — в классический код приложения.

PostgREST преобразует вашу схему Postgres в REST API — фильтры, внедрение отношений, RPC, RLS, управляемые JWT — без необходимости писать серверную часть. Мы подробно описываем эту область в нашей статье о ее реальной совместимости с и ее альтернативами; для этого сравнения важно то, где останавливается PostgREST.

В PostgREST нет понятия произвольной бизнес-логики. Каждое правило должно быть выражено на SQL: функция RPC, триггер, ограничение, политика RLS. Это общепринятое ограничение, а не упущение: диаграмма остается единственным источником истины, который устраняет любые расхождения между уровнем приложения и базой, которую оно обслуживает.

Конкретно, невозможно позвонить в стороннюю платежную службу, отправить электронное письмо с подтверждением или подсчитать счет в JavaScript из прямого запроса PostgREST. Эта логика должна либо находиться в SQL (функция pl/pgsql), либо запускаться снаружи — триггер, который публикует событие NOTIFY, прослушиваемое внешней службой, которая больше не является PostgREST.

В нашей статье о слоях GraphQL в Postgres подробно рассказывается, где работает движок Hasura и чем его разрешения отличаются от разрешений Postgres RLS. Здесь речь идет о бизнес-логике: как и где подключить собственный код к базе данных, управляемой Hasura.

Действие Hasura предоставляет пользовательскую мутацию или запрос GraphQL, поддерживаемый веб-перехватчиком HTTP, который вы пишете на выбранном вами языке. Hasura проверяет входные данные в соответствии с объявленной схемой, вызывает ваш вебхук, а затем возвращает ответ клиенту. Это шлюз для любой логики, выходящей за рамки CRUD: вызов поставщика платежей, сложные вычисления, многоэтапная оркестровка.

Триггеры событий действуют в противоположном направлении: вставка, обновление или удаление таблицы запускает веб-перехватчик асинхронно и с автоматическим перезапуском в случае сбоя. Это механизм, который большинство интеграций Hasura используют для синхронизации сторонней службы (биллинга, транзакционной электронной почты, поисковой системы) без привязки этого кода к первоначальному запросу клиента.

Hasura также может предоставлять уже написанный запрос GraphQL как типичный REST-маршрут с именованным путем и параметрами — его конечными точками RESTified, в терминологии собственной документации. Полезно, если ваша команда веб-интерфейса предпочитает использовать REST, не отказываясь от базового механизма разрешений GraphQL.

Контекстное напоминание, разработанное в нашей специальной статье: с июня 2025 года Hasura переориентировала свое общение на PromptQL, уровень, предназначенный для агентов ИИ, не удаляя свой движок GraphQL, который до сих пор представлен на своем официальном сайте как «проверенный в бою».

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

// Фильтр, сортировка и встраивание отношений написаны вручную.
// только для этого маршрута — повторите для каждого ресурса API
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

Что предлагает эта модель в обмен на ручную работу: полный контроль над ошибками и возвращаемыми HTTP-кодами, классическую возможность тестирования (обработчики, а не декларативная конфигурация) и отсутствие необходимости изучать новый DSL для команды, которая уже владеет его языком.

Взамен чего это стоит: CRUD, нумерация страниц и фильтры, которые нужно писать и поддерживать вручную для каждого ресурса; аутентификация и авторизация для самостоятельного внедрения и аудита без автоматически наследуемого RLS; риск запросов N+1, если каждое вложенное отношение запускает собственный запрос Postgres без дисциплины; и документация API должна поддерживаться вручную или с помощью стороннего генератора для интеграции.

Что касается чистой производительности, вопрос «Является ли Node.js медленнее, чем Rust» является отдельной темой — наша статья о Rust и задержке Node.js подробно описывает его, а методология объявлена ​​выше на нашей странице методологии тестирования . Пользовательский API имеет тот же профиль производительности, что и любой HTTP-сервис, который вы уже используете, не лучше и не хуже по своей конструкции. Чтобы точно знать, где PostgREST насыщается и в какой момент становится необходим пользовательский уровень, прочтите нашу статью о реальных ограничениях PostgREST в производстве.

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

В проекте движка Aurabase Postgres уровень CRUD уже покрыт реальным экземпляром PostgREST, а не приблизительной повторной реализацией. Вопрос, который остается открытым для этого сравнения: куда писать то, что выходит за рамки CRUD?

Существуют два пути, и они не исключают друг друга. Первый: функция SQL, представленная в RPC, для любой логики, которую разумно выразить в SQL — подсчет итога, перекрестная проверка между несколькими таблицами, каскадные обновления в одной транзакции.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

Второй способ: Edge Functions, для всего, что выходит за рамки SQL-домена — вызов платежного API, отправка электронного письма, расчет встраивания. В Aurabase к этому ведут два пути: редактор Studio, который запускает код Deno (TypeScript) точно так же, как в Supabase, и CLI aura functions deploy, который предназначен для отдельного пути для функций, написанных на Rust и скомпилированных в WASM — подробно описанных в нашей унифицированной архитектуре Rust . Ни один из вариантов не требует размещения отдельного Node-сервера, в отличие от варианта «пользовательского API» в этой статье, где ответственность за этот сервер полностью лежит на вас.

Этот дистрибутив не является шатким компромиссом между тремя сравниваемыми здесь моделями: это буквально PostgREST для CRUD, кирпичик, близкий к Hasura Actions для логики событий через RPC и триггеры, и Edge Functions, которые избегают работы полного сервера приложений - без необходимости делать двоичный выбор между «всеми PostgREST» и «всеми пользовательскими».

Чаще всего возникают четыре ситуации. Правильный выбор зависит главным образом от требований вашей бизнес-логики, а не от популярности инструмента.

• Ваша схема стабильна, а ваша бизнес-логика написана на SQL. Самостоятельного PostgREST или встроенной интеграции (Aurabase, Supabase) достаточно: размещать больше нечего, и схема остается единственным источником истины.
• Вы хотите объединить несколько источников данных или ваш план действий ориентирован на агентов ИИ, потребляющих ваши данные. Hasura со своим слоем PromptQL лучше подходит для этой местности.
• Ваш продукт имеет богатую бизнес-логику, множество сторонних интеграций и команду, уже оснащенную языком приложения. Пользовательский API остается наиболее прямым выбором за счет его написания и поддержки с течением времени.
• Вам нужен самогенерируемый CRUD, не оставляющий реального места для бизнес-логики (RPC, Edge Functions), без создания еще одного сервиса приложений для использования. Это угол, описанный в сравнении с Aurabase (см. предыдущий раздел).