pg_graphql は、Supabase によって管理されているオープンソースの Postgres 拡張機能であり、Aurabase の発明ではありません。私たちが構築したのは、プラットフォームへのネイティブおよびオプトイン統合です。プロビジョニングするサービスではなく、プロジェクトごとにチェックを入れるボックスです。この投稿では、実際のアーキテクチャを詳しく説明し、それを有効にする方法を示し、Hasura および PostGraphile v5 とのトレードオフを正直に比較します。
pg_graphqlは SQL 拡張機能として Postgres で実行されます。Hasura や PostGraphile とは異なり、個別の GraphQL サーバーをデプロイする必要はありません。- Aurabase が提供するラッパー関数は
SECURITY INVOKERです。RLS ポリシーは自動的に適用され、並行して維持するための 2 番目の権限システムは必要ありません。 - オプトイン アクティベーションはプロジェクトごとにのみ (
aura projects graphql-enableまたは Studio)、どのプロジェクトでもデフォルトでアクティベートされることはありません。 - Hasura は、GraphQL エンジンを放棄することなく、2025 年 6 月に正式に PromptQL と AI エージェントに再び焦点を当てました。
- PostGraphile v5 は、2026 年 3 月 24 日に一般公開されました。これは、休止中のプロジェクトではなく、直接のアクティブな競合相手です。
pg_graphql を一文で
pg_graphql は SQL スキーマをイントロスペクトし、Relay 規約 ( <table>Collection、 edges、 node) に準拠した GraphQL スキーマを生成し、列タイプによるフィルター、カーソルによるページネーションを行います。 SDL を手動で記述したり保守したりする必要はありません。GraphQL スキーマは Postgres スキーマに従います。
アーキテクチャにとって重要な点: このスキーマ ジェネレーターは、隣の HTTP プロセスとしてではなく、SQL 関数としてデータベース内に存在します。 Aurabase は、拡張機能の 1.6.1 バージョン (2026 年 5 月 7 日リリース) を Postgres イメージ — Supabase によって配布されているものと同じ公式 .deb パッケージに固定します。これは、共有クラスターと専用の Postgres インスタンスの両方にインストールされます。
pg_graphql が長い間ネイティブに有効になってきた Supabase を使用している場合は、このロジックには馴染みがあるでしょう。詳細な の比較 と 移行ガイド では、残りの RLS スキーマとポリシーについて説明していますが、それらは同じです。
Hasura と PostGraphile で何が変わったのか
「Postgres 上のインスタント GraphQL」の 2 つの歴史的な競合他社はどちらも消滅していません。彼らの位置づけは変化しており、更新された記事では 2 年前の状態を引用するのではなく、それを反映する必要があります。
Hasura は 2025 年 6 月に、共同創設者の Tanmai Gopal の署名付きで「GraphQL から PromptQL へ: 新しい章の始まり」という明示的なタイトルの投稿を公開しました。メッセージ: 同社は、AI エージェント向けに設計されたデータ アクセス レイヤーである PromptQLにロードマップを再度焦点を当てています。 GraphQL エンジンは削除されていません。Hasura のホームページには依然として「厳しいテスト済み」と表示されていますが、優先メッセージではなくなりました。
PostGraphileは、その逆のことを行いました。 2023 年からベータ版として開発が進められてきたバージョン 5 は、Grafast と呼ばれる新しいクエリ プランニング エンジンを備え、2026 年 3 月 24 日に一般公開されました。これは勢いがなくなっているプロジェクトではありません。最後のリリース 5.1.4 は、2026 年 8 月 5 日の日付です。npm パッケージ は、2026 年 8 月 16 日から 22 日の週だけで 119,230 件のダウンロードを記録しました (npm レジストリ、2026 年 8 月 23 日に調査)。
実際の結果: 本当の空きスペースは「Postgres 上の GraphQL、誰も触っていない」ものではありません。それは、ホストするサービスのない、1 つのコマンドでアクティブ化された特定の GraphQL ゼロ構成スロットです。ハスラは戦略的選択によってそこから遠ざかります。 PostGraphile はこれをターゲットにしたことはなく、そのモデルは「自分自身を統合するための Node.js ライブラリ」のままです。
それぞれのソリューションが実際にどこに向かうのか
運用コスト、攻撃対象領域、レイテンシなど、他のすべてを構成する違いは、GraphQL エンジンが実行される場所です。
| どこに転ぶのか | Postgres の SQL 拡張機能 | Postgres の前にある別の GraphQL サーバー (Go) | Node.js ライブラリ/サーバー、Postgres よりも先 |
|---|---|---|---|
| 導入が必要です | なし — プロジェクト フラグによってアクティブ化されます | はい — Hasura エンジンをホストし、スケーリングします | はい - ノードプロセスをホストするか、サーバーと統合します |
| 権限モデル | レガシー Postgres RLS (SECURITY INVOKER) | Hasura 独自の権限システム (ロール/テーブルごと) | pgSettings 経由の RLS Postgres — ネイティブ委任も |
| デフォルトでのイントロスペクション | 障害者 | エンジン構成に応じて | サーバー構成に応じて |
| 2026 年の位置付け | Postgres BaaS のネイティブ オプション | 2025 年 6 月から PromptQL/IA に再び焦点を当てる | 2026 年 3 月以降の GA v5、アクティブなプロジェクト |
| オーラベース | ハスラ | ポストグラフィック V5 |
正直に言うと、PostGraphile は pgSettings とロール切り替えを介して Postgres に承認を委任します。ネイティブ RLS は pg_graphql に限定されたものではありません。依然として異なるのは、誰がこのブリッジをホストして構成するかということです。PostGraphile では、それはあなたです。 Aurabase では、これはすでに行われています。
Aurabase がプロジェクトで pg_graphql をアクティブ化する方法
アクティベーションはオプトインでプロジェクトごとに行われ、Postgres エンジン プロジェクト用に予約されています。MongoDB プロジェクトはリクエスト (GRAPHQL_UNSUPPORTED_ENGINE) を拒否します。 pg_graphql は Postgres 拡張機能であり、他のエンジンには同等のものはありません。
CLI を使用するか、管理プランを直接呼び出します。
サーバー側では、この呼び出しにより、プロビジョナーが 1 つのトランザクションで実行する graphql_enable ジョブが実行されます。これには、拡張機能のインストール、スキーマでの graphql() 関数の作成、アプリケーション ロールへの GRANT が含まれます。ステップが失敗すると、すべてがキャンセルされます。ラッパーが途中でインストールされることはありません。graphql_enabled は、完全に成功した場合にのみ true に移行します。
これは、共有 Postgres クラスターとプロジェクトごとの専用 CNPG インスタンスの両方で動作します。2 つの異なる Postgres イメージですが、拡張メカニズムは同じです。専用インスタンスでは、拡張機能は直接 SQL ではなく、CNPG オペレーターの宣言マニフェストを介してインストールされます (最近の修正)。専用クラスターはアプリケーション スーパーユーザー アクセスなしで実行され、 pg_graphql はその CREATE EXTENSIONに対してまさにこの権限を必要とします。
Studio からは、同じフローが [テーブル構成] タブを通過します。そこにあるボタンは、プロジェクト レベルで拡張機能をアクティブ化します。これは、上記と同じ HTTP 呼び出しで、収束するまでポーリングが行われます。次に、2 番目のコントロールは、エディターを離れることなく、テーブルごとに @graphql ディレクティブを設定し、GraphQL コレクションの totalCount と集計フィールドをアクティブにするかどうかを設定します。
単一コマンド ビュー: アクティブ化 → スレッド化されたプロビジョニング ジョブ (冪等、すでに実行中の場合は操作なし) → DDL トランザクション (拡張機能、ラッパー関数、GRANT) → 完全な成功後にのみフラグ graphql_enabled が設定される → /rpc/graphql経由でリクエストが可能。
レガシー RLS、保守が必要な 2 番目のシステムではない
Aurabase によって設定された関数は SECURITY INVOKER です。これは Postgres のデフォルトの動作であり、将来のリファクタリングによって誤って変更されないように説明されています。実際の呼び出し元 (JWT クレームに応じてaura_anon、 aura_authenticated または aura_service_role) の権限で実行されるため、 RLS ポリシー は REST リクエストの場合とまったく同じように適用されます。
SECURITY DEFINER 関数は RLS 全体をバイパスします — 内部的にチェックされます。アプリケーション ロールを変更せずにスーパーユーザー接続で graphql.resolve を呼び出すと、RLS かどうかにかかわらず、すべての所有者の行が返されます。この選択により、まさにクロステナントのリスクが回避されます。
Hasura では、アーキテクチャは構造によって異なります。エンジンは各 GraphQL クエリを、Hasura に固有の権限ルールによって制約された SQL クエリに変換します。これらのルールは、Postgres RLS への委任ではなく、Postgres RLS への並列システムである独自のレイヤー内のロールごとおよびテーブルごとに定義されます。アクセス ルールを監査する場所は 1 つではなく 2 つです。
イントロスペクション ({ __schema { ... } }) は、各 Aurabase プロジェクトでデフォルトで無効のままです。これは、プラットフォームの他の部分と一貫した姿勢です。 Apollo Studio やgraphql-codegen などのツールが必要な場合は、COMMENT ON SCHEMA を介してスキーマによってアクティブ化できます。
GraphQL API を有効にしてクエリを実行します
graphql_enabled から trueに移行すると、専用の /graphql ルートがゲートウェイに表示されなくなります。リクエストは、SDK から呼び出される他の Postgres 関数と同様に、汎用の RPC プロキシを経由します。
レスポンスは、追加の Aurabase ラッピングなしで、GraphQL 仕様 ({ data, errors }) に従います。ゲートウェイは、ターゲットの RPC が graphql であることを検出し、通常の RPC とは異なり、再ラップしません。標準の GraphQL クライアント (Apollo、urql、graphql-request) は出力をそのまま使用します。
アクティブ化時に、図の @graphql ディレクティブを介して、 max_rows: 1000 および inflect_names: trueという 2 つの設定がデフォルトで設定されます。 pg_graphql のデフォルトの上限はコレクションあたり 10,000 行です。 first:を使用しないと、大きなテーブルがメモリを飽和させる可能性があります。 inflect_names は、SQL テーブルの生のsnake_caseではなく、読み取り可能な型名を提供します。
pg_graphql が (まだ) できないこと
このブログの精神に沿って、隠すのではなく文書化すること。
- ネイティブ GraphQL サブスクリプションがありません。 pg_graphql は、リアルタイム
subscriptionsではなく、クエリとミューテーションをカバーします。これは拡張機能自体の制限であり、Aurabase の省略ではありません。リアルタイム Aurabase は存在しますが、GraphQL サブスクリプション ブリッジではなく、別のチャネル (postgres_changes) を介して存在します。 - Hasura のような宣言的なアクションはありません。 「GraphQL ミューテーションに接続されたビジネス Webhook」モデルには直接同等のものはありません。Aurabase では、このロジックは専用の GraphQL 設定ではなく、Postgres 関数または Edge 関数を経由します。
- Postgres エンジン用に予約されています。 MongoDB プロジェクトではこれを有効にできません。回避策はありません。
アクティベーションがデフォルトではなくオプトインのままである理由: テナント データベースの GRANT/Roles 領域には、リグレッションの文書化された履歴があります。これは、より広範な欠陥を検討する前に、プロジェクトごとに明示的な検証を行わない限り、機能が影響を受けないことを正当化するのに十分です。
Aurabase、Hasura、PostGraphile: コンテキストに応じて
3 つのオプションはすべて正当です。正しい選択は、すでに持っているものと避けたいものによって異なります。
- Aurabase の pg_graphql — RLS データベースとポリシーがすでに Aurabase 上に存在しており、追加の監視サービスなしでクエリを実行する 2 番目の方法が必要な場合。
- Hasura — 単一の GraphQL スキーマの背後で複数のデータ ソース (Postgres だけでなく) をフェデレーションする場合、または PromptQL とその AI エージェントのアプローチがロードマップに適合する場合。
- PostGraphile v5 — プラグイン システム経由で生成されたスキーマを細かく制御する必要があり、それを統合する Node.js サーバーをすでに実行している場合。
完全なクエリ構文 (列タイプによるフィルター、orderBy並べ替え、カーソルによるページネーション、insertInto<Table>Collection 変更) については、公式の pg_graphqlドキュメントを参照してください。以下の Aurabase GraphQL ドキュメントでも、完全なサイクルについて詳しく説明しています。