Совместимость PostgREST: что она охватывает и альтернативы

PostgREST — это автономный веб-сервер, который преобразует существующую базу данных PostgreSQL в REST API непосредственно из ее схемы. Никакого прикладного уровня для записи: таблицы, представления и функции становятся маршрутами, а разрешения SQL — ролями, политиками RLS — становятся уровнем авторизации.

Конкретно PostgREST охватывает пять возможностей, которые встречаются почти во всех оценках:

• Горизонтальная фильтрация — около тридцати операторов (eq, gt, like, ilike, in, is, cs, ov, fts...) непосредственно в строке запроса.
• Вертикальная фильтрация и внедрение — ?select= проецирует столбцы и внедряет связи через внешний ключ, например customer:customers(email).
• RPC — POST /rpc/{fonction} напрямую вызывает функцию SQL, которая становится конечной точкой.
• RLS, управляемый JWT — PostgREST переключает активную роль Postgres в соответствии с полученным токеном (SET LOCAL ROLE), поэтому ваши политики применяются как есть, без дублирования логики авторизации на стороне приложения.
• Самогенерируемый OpenAPI — спецификация выводится из открытой схемы без файла, который нужно поддерживать вручную.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

Один HTTP-запрос фильтрует оплаченные заказы, встраивает электронную почту клиента с помощью внешнего ключа и сортирует по дате — без необходимости прописывать отдельный маршрут вручную.

RPC следует той же логике: функция SQL, уже написанная в вашей базе данных, становится конечной точкой POST, а ее аргументы передаются в формате JSON.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Этот принцип (схема Postgres является единственным источником истины API) делает PostgREST предсказуемым: каждое изменение поведения происходит через миграцию SQL, а не через отдельный уровень приложения, который может быть получен из реальной схемы. Проект с открытым исходным кодом, разработанный на GitHubнезависимо от какого-либо конкретного поставщика BaaS.

PostgREST разрешает уровень CRUD. Он не разрешает остальную часть серверной части приложения. Четыре недостатка систематически возникают среди команд, которые применяют его в одиночку.

• Аутентификация — без выдачи JWT или интегрированного управления пользователями. Вы должны создать его на SQL или делегировать внешней службе.
• Файловое хранилище — нет. Ведро S3 или его аналог необходимо подключить отдельно.
• Real time — PostgREST отвечает на одноразовые HTTP-запросы, не отправляя никаких событий.
• Пул соединений — PostgREST сам подключается к Postgres, но не интегрирует какие-либо расширенные средства пула. В масштабе управление им становится самостоятельным операционным решением: пулер в классическом режиме транзакций конфликтует с механизмом перезагрузки схемы PostgREST (см. ниже, как Aurabase разрешает этот компромисс).

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

В проекте движка Aurabase Postgres (движок по умолчанию) шлюз направляет каждый запрос CRUD непосредственно в экземпляр PostgREST v12.2.8, выделенный для этого проекта, две реплики, расположенные рядом с кластером Postgres арендатора. Это не приблизительная совместимость: это сам исходный двоичный файл PostgREST с теми же операторами, тем же внедрением, тем же RPC, тем же RLS, управляемым JWT.

В проекте движка MongoDB ситуация иная. У MongoDB нет эквивалента PostgREST: эти запросы перенаправляются во внутренний сервис Aurabase, который переопределяет подмножество тех же соглашений — идентичные имена операторов, синтаксис ?select= с встраиванием, заголовки Prefer и Content-Range — но в механизме документов, а не в реляционном. Этот уровень имеет свои ограничения: встраивание, запрошенное в представление, возвращаемое мутацией, явно отвергается, а не игнорируется молча, и не существует маршрута RPC, эквивалентного функциям SQL.

Техническая деталь контрастирует с интуицией: каждый выделенный экземпляр PostgREST остается напрямую подключенным к основному Postgres, минуя пулер PgBouncer, развернутый для этого клиента. Предполагаемая причина: режим пула транзакций нарушит перезагрузку схемы PostgREST, которая опирается на LISTEN/NOTIFY — постоянное соединение, несовместимое с пулом, который перезапускает соединение для каждой транзакции.

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

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

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

Момент, который часто недооценивают при выборе «самостоятельного размещения»: PostgREST сам по себе остается легким для запуска, но производственная операция (обновление версии, высокая доступность, связь с пулером, мониторинг) остается полностью вашей ответственностью — именно эта операционная работа, а не программное обеспечение, поглощается управляемыми платформами.

Подробное сравнение подходов GraphQL — pg_graphql, Hasura и PostGraphile — смотрите в нашей статье, посвящённой GraphQL API на Postgres.

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

• Вам просто нужен REST API поверх существующей схемы Postgres, и ничего больше. Самостоятельного PostgREST достаточно: он делает именно то, что делает, и больше ничего устанавливать не нужно.
• Вам нужна дополнительная аутентификация, хранилище и реалтайм, и вы готовы собрать несколько сервисов. Supabase или PostgREST в сопровождении вашего собственного стека приложений удовлетворяет эту потребность.
• Вы предпочитаете GraphQL REST. Hasura или PostGraphile покрывают эту тему — другой архитектурный выбор, а не прямая замена PostgREST.
• Вам нужен полноценный бэкэнд Postgres без объединения нескольких отдельных сервисов. Это тот ракурс, который документирует наша унифицированная архитектура Rust: настоящий PostgREST для уровня CRUD, изначально окруженный функциями аутентификации, хранения, реального времени и пограничных функций.