pg_graphql vs Hasura and PostGraphile on Postgres

pg_graphql introspects your SQL schema and generates a GraphQL schema conforming to the Relay convention — <table>Collection, edges, node, filters by column type, pagination by cursor. No SDL to write or maintain by hand: the GraphQL schema follows your Postgres schema.

The point that matters for the architecture: this schema generator lives inside the database, as an SQL function, not as an HTTP process next to it. Aurabase pins the 1.6.1 version of the extension (released May 7, 2026) in its Postgres image — the same official .deb package as distributed by Supabase. It is installed both on the shared cluster and on the dedicated Postgres instances.

If you come from Supabase, where pg_graphql has been natively enabled for a long time, the logic will be familiar to you. Our detailed comparison and our migration guide cover the rest of the RLS schema and policies, which remain the same.

Neither of the two historical competitors of “instant GraphQL on Postgres” has disappeared. Their positioning has shifted, and an updated article should reflect that rather than citing the state of two years ago.

Hasura published a post in June 2025 with the explicit title, “From GraphQL to PromptQL: A New Chapter Begins”, signed by its co-founder Tanmai Gopal. The message: the company is refocusing its roadmap on PromptQL, a data access layer designed for AI agents. The GraphQL engine is not removed - Hasura's home page still presents it as "battle-tested" - but it is no longer the priority message.

PostGraphile, for its part, did the opposite. Its version 5, in development since 2023 in the form of betas, became generally available on March 24, 2026, with a new query planning engine called Grafast. This is not a project that is running out of steam: the last release, 5.1.4, dates from August 5, 2026. The npm package counted 119,230 downloads in the week of August 16 to 22, 2026 alone (npm registry, consulted August 23, 2026).

The difference that structures everything else — operating cost, attack surface, latency — is where the GraphQL engine runs.

To be honest: PostGraphile also delegates authorization to Postgres via pgSettings and role switching — native RLS is not exclusive to pg_graphql. What remains different is who hosts and configures this bridge: at PostGraphile, it's you; at Aurabase, this is already done.

Activation is opt-in, per project, and reserved for Postgres engine projects — a MongoDB project refuses the request (GRAPHQL_UNSUPPORTED_ENGINE), pg_graphql being a Postgres extension with no equivalent on the other engine.

Via the CLI or by directly calling the management plan:

# Idempotent: recalling an already activated project does not recreate anything
aura projects graphql-enable <project_id>

# HTTP equivalent (management plane, JWT console)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

On the server side, the call executes a graphql_enable job that the provisioner executes in a single transaction: installation of the extension, creation of the graphql() function in your schema, GRANTs to the application roles. If a step fails, everything is canceled — never a wrapper installed halfway, and graphql_enabled only moves to true after complete success.

It works both on the shared Postgres cluster and on a dedicated CNPG instance per project — two different Postgres images, but the same extension mechanism. On dedicated instances, the extension is installed via the declarative manifest of the CNPG operator rather than direct SQL — a recent correction. A dedicated cluster runs without application superuser access, and pg_graphql requires precisely this privilege for its CREATE EXTENSION.

From the Studio, the same flow goes through the Table Configuration tab. A button there activates the extension at the project level — the same HTTP call as above, with polling until convergence. A second control then sets a @graphql directive per table, to activate or not totalCount and the aggregation fields on its GraphQL collection, without leaving the editor.

Single command view: activation → provisioning job threaded (idempotent, no-op if already in flight) → DDL transaction (extension, wrapper function, GRANTs) → flag graphql_enabled set only after complete success → requests possible via /rpc/graphql.

The function set by Aurabase is SECURITY INVOKER — default behavior of Postgres, explained so that a future refactor does not change it by accident. It runs with the privileges of the actual caller (aura_anon, aura_authenticated or aura_service_role, depending on the JWT claim), so your RLS policies apply exactly as for a REST request.

At Hasura, the architecture is different by construction: the engine converts each GraphQL query into an SQL query constrained by permission rules specific to Hasura. These rules are defined per role and per table in its own layer — a parallel system to the Postgres RLS, not a delegation to it. Two places to audit access rules, instead of just one.

Introspection ({ __schema { ... } }) remains disabled by default on each Aurabase project — a posture consistent with the rest of the platform. It can be activated by schema via COMMENT ON SCHEMA if a tool like Apollo Studio or graphql-codegen needs it.

Once graphql_enabled to true, no dedicated /graphql route appears on the gateway. The request goes through the generic RPC proxy, just like any Postgres function called from the SDK.

curl -X POST "$AURA_URL/v1/db/$PROJECT_ID/rpc/graphql" \
  -H "apikey: $AURA_ANON_KEY" -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { postsCollection(first: 10, filter: { published: { eq: true } }) { edges { node { id title created_at } } } }"}'

The response follows the GraphQL spec — { data, errors } — without additional Aurabase wrapping: the gateway detects that the targeted RPC is graphql and does not rewrap it, unlike an ordinary RPC. A standard GraphQL client (Apollo, urql, graphql-request) consumes the output as is.

Two settings are set by default upon activation, via a @graphql directive on the diagram: max_rows: 1000 and inflect_names: true. pg_graphql caps by default at 10,000 rows per collection — without first:, a large table can saturate memory. inflect_names gives readable type names rather than the raw snake_case of SQL tables.

To be documented rather than hidden, in the spirit of this blog.

• No native GraphQL subscriptions. pg_graphql covers queries and mutations, not real-time subscriptions — this is a limitation of the extension itself, not an Aurabase omission. Real-time Aurabase exists, but through a separate channel (postgres_changes), not a GraphQL subscriptions bridge.
• No declarative actions à la Hasura. The “business webhook connected to a GraphQL mutation” model has no direct equivalent — on Aurabase, this logic goes through a Postgres function or an Edge Function, not through a dedicated GraphQL configuration.
• Reserved for the Postgres engine. A MongoDB project cannot enable this — no workaround intended.

All three options are legitimate — the right choice depends on what you already have and what you're looking to avoid.

• pg_graphql on Aurabase — if your RLS database and policies already live on Aurabase and you want a second way to query it without additional services to monitor.
• Hasura — if you federate multiple data sources (not just Postgres) behind a single GraphQL schema, or if PromptQL and its AI agent approach fit your roadmap.
• PostGraphile v5 — if you want fine control over the schema generated via its plugin system, and you already run a Node.js server into which to integrate it.

For full query syntax — filters by column type, orderBysorting, pagination by cursor, insertInto<Table>Collection mutations — see the official pg_graphqldocumentation. The Aurabase GraphQL documentation, below, also details the full cycle.