PostgREST 対 Hasura 対 カスタム API

「PostgREST か Hasura かカスタム API」という質問には、より有益な質問が隠されています。それは、誰がどのツールを使用してビジネス ロジックを作成し、運用環境でこのコードを使用するのは誰ですか?ということです。 3 つのアーキテクチャは対応が異なり、この違いがセキュリティ、実装の速度、長期的な技術的負債など、他のすべてを構造化します。

厳密には 3 つの列のどれも優れているわけではありません。それぞれが作業を別の場所に移します。 PostgREST は SQL に、Hasura は構成と Webhook に、カスタム API はクラシック アプリケーション コードに移行します。

PostgREST は、Postgres スキーマを REST API (フィルター、リレーションシップの埋め込み、RPC、JWT 駆動の RLS) に変換します。書き込むバックエンドはありません。このスコープについては、実際の 互換性と の代替案に関する記事で詳しく説明しています。この比較で重要なのは、PostgREST がどこで停止するかです。

PostgREST には、任意のビジネス ロジックの概念がありません。 RPC 関数、トリガー、制約、RLS ポリシーなどの各ルールは SQL で表現する必要があります。これは許容された制約であり、見落としではありません。図は依然として唯一の真実の情報源であり、アプリケーション層とそれが提供するベースとの間のあらゆるドリフトを排除します。

具体的には、直接の PostgREST リクエストからサードパーティの支払いサービスを呼び出したり、確認メールを送信したり、JavaScript でスコアを計算したりすることは不可能です。このロジックは SQL (pl/pgsql 関数) 内に存在するか、外部でトリガーされる (NOTIFYイベントを発行するトリガーで、PostgREST ではなくなった外部サービスによってリッスンされる) 必要があります。

Our article on GraphQL layers on Postgres details where the Hasura engine runs and how its permissions differ from the Postgres RLS. Here, the angle is that of business logic: how to plug custom code into a database managed by Hasura, and where.

アクション Hasura は、選択した言語で作成した HTTP Webhook を基盤としたカスタム GraphQL ミューテーションまたはクエリを公開します。 Hasura は、宣言されたスキーマに従って入力を検証し、Webhook を呼び出し、その応答をクライアントに返します。これは、CRUD を超えるあらゆるロジック (決済プロバイダーへの呼び出し、複雑な計算、複数ステップのオーケストレーション) へのゲートウェイです。

イベント トリガー は逆の方向に従います。テーブルの挿入、更新、または削除により Webhook が非同期的にトリガーされ、障害発生時に自動的に再起動されます。これは、ほとんどの Hasura 統合が、このコードを最初の顧客リクエストに結合することなく、サードパーティ サービス (請求、トランザクション電子メール、検索エンジン) を同期するために使用するメカニズムです。

Hasura は、すでに作成された GraphQL クエリを、名前付きパスとパラメーター (独自のドキュメントの用語では RESTifiedエンドポイント) を使用して、典型的な REST ルートとして公開することもできます。フロントエンド チームが、基盤となる GraphQL 権限エンジンを放棄せずに REST を使用したい場合に便利です。

私たちの専用記事で開発されたコンテキスト リマインダー: Hasura は、2025 年 6 月以降、AI エージェント向けに設計されたレイヤーである PromptQL でのコミュニケーションに再び焦点を当てています。GraphQL エンジンは削除されず、公式 Web サイトではまだ「厳しいテスト済み」として表示されています。

定義上、手書きの API には制限がありません。あらゆるビジネス ロジック、あらゆる言語、あらゆる依存関係が含まれます。また、これは、3 つのオプションのうち、何も生成されない唯一のオプションです。すべてのルート、すべての検証、データベースへのすべての接続は、ユーザーが所有し、保守する必要があるコードです。

// フィルター、ソート、リレーションシップの埋め込みは手作業で書かれています。
// このルートのみ - 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 を使用せずに、自分自身で実装および監査するための認証と許可。ネストされた各関係が規律なしに独自の Postgres クエリをトリガーした場合、N+1 クエリが発生するリスク。 API ドキュメントは手動で維持するか、サードパーティのジェネレーターを介して統合する必要があります。

生のパフォーマンスに関しては、「Node.js は Rust よりも遅いのか」という質問は、それ自体がトピックです。 Rust と Node.js のレイテンシーに関する記事 では、 ベンチマーク方法論ページでアップストリームに宣言されている方法論を使用して詳細に説明しています。カスタム API は、すでに使用している HTTP サービスと同じパフォーマンス プロファイルを持ち、構造によって良くも悪くもなりません。 PostgREST がどこで飽和し、どの時点でカスタム レイヤーが必要になるかを正確に知るには、 運用環境における PostgREST の実際の制限に関する記事を参照してください。

アーキテクチャ以外にも、実装の速度、実際のビジネスの柔軟性、長期的な技術的負債、各オプションが最も快適な一般的な使用例という 4 つの基準が選択の際によく考えられます。

Aurabase Postgres エンジンプロジェクトでは、CRUD レイヤーは、近似的な再実装ではなく、実際の PostgREST インスタンスによってすでにカバーされています。この比較に関して未解決のままの疑問は、CRUD を超えるものをどこに記述するかということです。

2 つのパスが存在し、相互に排他的ではありません。 1 つ目: RPC で公開される SQL 関数。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"}'

2 番目の方法: エッジ関数。決済 API の呼び出し、電子メールの送信、埋め込みの計算など、SQL ドメインを超えるあらゆるものに対応します。 Aurabase では 2 つのパスがそこに通じています。Supabase とまったく同じように Deno (TypeScript) コードを実行する Studio エディターと、Rust で書かれ WASM でコンパイルされた関数の別のパスを目指す aura functions deployCLI です。詳細については、 統合 Rust アーキテクチャを参照してください。この記事の純粋な「カスタム API」オプションとは異なり、どちらのパスでも別のノード サーバーをホストする必要はありません。サーバーは完全にユーザーの責任です。

このディストリビューションは、ここで比較した 3 つのモデル間の不安定な妥協点ではありません。文字通り、CRUD 用の PostgREST、RPC とトリガーを介したイベント ロジック用の Hasura Actions に近いブリック、および完全なアプリケーション サーバーの操作を回避するエッジ機能です。「すべての PostgREST」と「すべてのカスタム」の間で二者択一を強制する必要はありません。

最も頻繁に現れるのは 4 つの状況です。正しい選択は、ツールの人気ではなく、ビジネス ロジックが何を必要とするかによって決まります。

• スキーマは安定しており、ビジネス ロジックは SQL です。 自己ホスト型 PostgREST、またはネイティブに統合された (Aurabase、Supabase) で十分です。これ以上ホストするものはなく、スキーマが唯一の信頼できる情報源のままです。
• 複数のデータ ソースを統合したい場合、またはロードマップが AI エージェントによるデータの利用を対象としている場合。 Hasura は PromptQL レイヤーを備えており、この領域によりよく適合します。
• あなたの製品には豊富なビジネス ロジック、多数のサードパーティ統合があり、チームはすでにアプリケーション言語を備えています。 カスタム API は依然として最も直接的な選択肢ですが、その作成と長期にわたる保守にはコストがかかります。
• ビジネス ロジック (RPC、エッジ関数) 用の実スペースを放棄したり、悪用するアプリケーション サービスをもう 1 つスタックしたりせずに、自己生成された CRUD が必要です。 これは、前のセクションの Aurabase に適用されたこの比較で文書化された角度です。