GraphQL
Postgres extension pg_graphql, opt-in per project and disabled by default. Once enabled, it exposes the same schema as your REST API — legacy RLS and roles, no separate GraphQL authentication — through the already existing generic RPC proxy, not a dedicated route.
A second way to query the same schema, not a separate service
GraphQL is not a separate HTTP route or service on the gateway: it is the Postgres extension pg_graphql (Supabase), which automatically generates a GraphQL schema from your actual SQL schema. What you're actually enabling, as a developer, is a second way of querying the same schema as your REST API — not a separate GraphQL backend with its own authentication or permissions.
Disabled by default, for all projects. Aurabase activates it only on explicit request, per project — never automatically for all of your projects. See the official pg_graphql doc for the full query syntax (filters, sorting, cursor paging, mutations).
An SQL wrapper, not a dedicated HTTP route
Enabling GraphQL on a project places, in a single transaction, the pg_graphql extension and a "<schéma_projet>".graphql(query, variables, operationName, extensions) function in your tenant schema. This function is then callable exactly like any Postgres function — via the generic RPC proxy already documented on /docs/api/database/rpc. There is no dedicated /graphql route on the gateway.
The activation transaction is all or nothing: in the event of failure on any of the steps (extension, function, GRANTs), everything is canceled (ROLLBACK) and graphql_enabled remains at false — never a wrapper half-placed.
What activation sets up
Automatically generated diagram
pg_graphql introspects your Postgres schema and exposes each table as a GraphQL type (Relay convention: <table>Collection, edges, node) — no SDL to write or maintain by hand.
§ schema generation
SECURITY INVOKER — Legacy RLS
The wrapper function placed in your diagram runs with the privileges of the caller (aura_anon / aura_authenticated / aura_service_role): the RLS policies apply exactly as for a REST request.
§ security
Introspection disabled by default
{ __schema { ... } } fails until explicitly re-enabled by schema — RLS-first posture consistent with the rest of the platform.
§ introspection
Opt-in activation, idempotent
POST .../graphql/enable (JWT console) or aura projects graphql-enable (CLI) thread a provisioning job; never activated by default, neither for a project nor for all projects.
§ activation
Available on all Postgres tiers
Works on the basis of your project, whether it lives on your organization's PostgreSQL cluster or on a fully dedicated cluster (Enterprise): the Postgres image embeds pg_graphql, activation validated end-to-end (extension, RLS wrapper, real query).
§ availability
Reserved for Postgres projects
A MongoDB engine project refuses activation (GRAPHQL_UNSUPPORTED_ENGINE) — pg_graphql is a Postgres extension, with no equivalent on the secondary engine.
§ engine
Activate, then query
Activation (CLI or REST) responds with the up-to-date project, graphql_enabled field included. For the full query syntax (filters by column type, sorting orderBy, pagination by cursor first/after, mutations insertInto<Table>Collection...), see the official pg_graphql API reference.
What GraphQL doesn't do
There is no /v1/db/{project_id}/graphqlendpoint. Once enabled, GraphQL queries exclusively through the generic RPC proxy (POST /v1/db/{project_id}/rpc/graphql), the same mechanism as any Postgres function invoked by aura.db.rpc().