PostgREST の互換性: 対象となる内容と代替案

PostgREST は、既存の PostgreSQL データベースをスキーマから直接 REST API に変換する自律型 Web サーバーです。アプリケーション層を記述する必要はありません。テーブル、ビュー、関数がルートになり、SQL 権限 (ロール、RLS ポリシー) が承認層になります。

具体的には、PostgREST は、ほぼすべての評価で登場する 5 つの機能をカバーしています。

• 水平フィルタリング — 約 30 個の演算子 (eq、 gt、 like、 ilike、 in、 is、 cs、 ov、 fts...) をクエリ文字列内で直接使用します。
• 垂直フィルタリングと埋め込み — ?select= は列を投影し、外部キー ( customer:customers(email)など) を介してリレーションシップを埋め込みます。
• RPC — POST /rpc/{fonction} は、エンドポイントとなる SQL 関数を直接呼び出します。
• JWT によって駆動される RLS — PostgREST は、受信したトークン (SET LOCAL ROLE) に応じてアクティブな Postgres ロールを切り替えるため、アプリケーション側で承認ロジックが重複することなく、ポリシーがそのまま適用されます。
• 自己生成 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 リクエストで、支払い済みの注文をフィルタリングし、外部キーを介して顧客の電子メールを埋め込み、日付順に並べ替えます。ルートを 1 つも手書きする必要はありません。

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 移行を経由します。このプロジェクトはオープンソースであり、特定の BaaS プロバイダーから独立した GitHub上で開発されています。

PostgREST は CRUD 層を解決します。アプリケーション バックエンドの残りの部分は解決されません。これを単独で採用するチームでは、体系的に 4 つの欠点が発生します。

• 認証 — JWT の発行や統合されたユーザー管理はありません。 SQL で構築するか、外部サービスに委任する必要があります。
• ファイル ストレージ — なし。 S3 バケットまたは同等のものは個別に接続されたままになります。
• リアルタイム — PostgREST は 1 回限りの HTTP リクエストに応答し、イベントをプッシュしません。
• 接続プーラー — PostgREST 自体は Postgres に接続しますが、高度なプーラーは統合しません。大規模になると、その管理はそれ自体で運用上の決定になります。クラシック トランザクション モードのプーラーは、PostgREST スキーマのリロード メカニズムと競合します (Aurabase がこの妥協をどのように解決するかを以下で参照してください)。

実際的な結果は明確に述べておく必要があります。認証がなければ、RLS ポリシーが匿名の顧客とデータの間の唯一のセキュリティ境界になります。 anon ロールに関する不適切に記述されたポリシーは、追加のアプリケーション層によって置き換えられることはありません。

Aurabase Postgres エンジンプロジェクト (デフォルトエンジン) では、ゲートウェイは各 CRUD リクエストをこのプロジェクト専用の PostgREST v12.2.8 インスタンス (テナントの Postgres クラスタと同じ場所にある 2 つのレプリカ) に直接ルーティングします。これはおおよその互換性ではありません。これは、同じ演算子、同じ埋め込み、同じ RPC、JWT によって駆動される同じ RLS を備えた PostgREST アップストリーム バイナリそのものです。

MongoDB エンジン プロジェクトの場合は話が異なります。 MongoDB には PostgREST に相当するものはありません。これらのリクエストは内部 Aurabase サービスにルーティングされ、同じ規則のサブセット (同一の演算子名、埋め込み付きの ?select= 構文、Prefer および Content-Range ヘッダー) が再実装されますが、リレーショナル エンジンではなくドキュメント エンジン上にあります。この層には独自の制限があります。ミューテーションによって返される表現で要求された埋め込みは、暗黙的に無視されるのではなく明示的に拒否され、SQL 関数に相当する RPC ルートがありません。

技術的な詳細は直感とは対照的です。各専用 PostgREST インスタンスは、このテナントにデプロイされた PgBouncer プーラーを経由せずに、プライマリ Postgres に直接接続されたままになります。想定される理由: トランザクション プーリング モードでは、LISTEN/NOTIFY (永続的な接続) に依存する PostgREST スキーマのリロードが中断され、トランザクションごとに接続をリサイクルするプールとは互換性がありません。

本番環境で役立つもう 1 つの詳細: 非アクティブなプロジェクトを一時停止してリソースを節約できます。スリープ状態のプロジェクトに対する最初のリクエストはウェイクアップをトリガーし、再試行遅延を伴う 503 を受け取ります。これは専用の PostgREST インスタンスが復帰するまでの時間です。コストとコールド レイテンシの間の想定される妥協点であり、隠れたインシデントではありません。

PostgREST には明確な用途があります。Postgres スキーマは信頼できる情報源であり、チームは CRUD レイヤーを手動で作成することを避けたいと考えています。この特定のケースとは別に、追加したいものに応じて、まったく何もないもの (裸の自己ホスト型) から、すぐに使用できる完全なバックエンドまで、いくつかの代替ファミリーが存在します。

以下の表は、各オプションがネイティブにカバーする内容と、各プロジェクトで選択されたアーキテクチャの価値判断を行わずに明示的にユーザーに委ねられる内容を比較しています。

「セルフホスト型」を選択するときに過小評価されがちな点です。PostgREST 自体は実行するのに軽いままですが、本番運用 (バージョン更新、高可用性、プーラーとの関連付け、監視) は完全にユーザーの責任になります。マネージド プラットフォームが吸収するのはソフトウェアではなく、この運用作業です。

GraphQL アプローチ (pg_graphql、Hasura、PostGraphile) 間の詳細な比較については、Postgres の GraphQL API に特化した記事 を参照してください。

最も頻繁に現れるのは 4 つの状況です。正しい選択は主に、自分で何を組み立て、保守するかによって決まります。

• 必要なのは既存の Postgres スキーマ上の REST API だけであり、他には何も必要ありません。 自己ホスト型 PostgREST で十分です。機能することはそのままで、他に何もインストールする必要はありません。
• 追加の認証、ストレージ、リアルタイムが必要であり、いくつかのサービスを組み立てる準備ができています。 Supabase、または独自のアプリケーション スタックを伴う PostgREST は、このニーズを満たします。
• あなたは REST よりも GraphQL を好みます。 Hasura または PostGraphile がこの領域をカバーします。これは、PostgREST を直接置き換えるものではなく、異なるアーキテクチャの選択です。
• 複数の個別のサービスをつなぎ合わせることなく、完全な Postgres バックエンドが必要です。 これは、が Rust アーキテクチャを統合した ドキュメントの角度です。つまり、認証、ストレージ、リアルタイム、およびエッジ関数によってネイティブに囲まれた、CRUD 層の実際の PostgREST です。