API GraphQL native sur Postgres avec pg_graphql : ce que Hasura et PostGraphile ne font pas pareil

pg_graphql introspecte votre schéma SQL et génère un schéma GraphQL conforme à la convention Relay — <table>Collection, edges, node, filtres par type de colonne, pagination par curseur. Aucun SDL à écrire ni à maintenir à la main : le schéma GraphQL suit votre schéma Postgres.

Le point qui compte pour l'architecture : ce générateur de schéma vit à l'intérieur de la base, comme fonction SQL, pas comme processus HTTP à côté. Aurabase pin la version 1.6.1 de l'extension (publiée le 7 mai 2026) dans son image Postgres — le même paquet .deb officiel que celui distribué par Supabase. Il est installé aussi bien sur le cluster partagé que sur les instances Postgres dédiées.

Si vous arrivez de Supabase, où pg_graphql est activé nativement depuis longtemps, la logique vous sera familière. Notre comparatif détaillé et notre guide de migration couvrent le reste du schéma et des policies RLS, qui restent identiques.

Aucun des deux concurrents historiques de « GraphQL instantané sur Postgres » n'a disparu. Leur positionnement a bougé, et un article à jour doit le refléter plutôt que de citer l'état d'il y a deux ans.

Hasura a publié en juin 2025 un billet au titre explicite, « From GraphQL to PromptQL: A New Chapter Begins », signé par son cofondateur Tanmai Gopal. Le message : l'entreprise recentre sa feuille de route sur PromptQL, une couche d'accès aux données pensée pour des agents IA. Le moteur GraphQL n'est pas retiré — la page d'accueil de Hasura le présente toujours comme « battle-tested » — mais il n'est plus le message porté en priorité.

PostGraphile, de son côté, a fait l'inverse. Sa version 5, en développement depuis 2023 sous forme de bêtas, est passée en disponibilité générale le 24 mars 2026, avec un nouveau moteur de planification de requêtes nommé Grafast. Ce n'est pas un projet qui s'essouffle : la dernière publication, la 5.1.4, date du 5 août 2026. Le paquet npm a compté 119 230 téléchargements sur la seule semaine du 16 au 22 août 2026 (registre npm, consulté le 23 août 2026).

La différence qui structure tout le reste — coût d'exploitation, surface d'attaque, latence — c'est l'endroit où le moteur GraphQL s'exécute.

À noter en toute honnêteté : PostGraphile délègue lui aussi l'autorisation à Postgres via pgSettings et le changement de rôle — la RLS native n'est pas exclusive à pg_graphql. Ce qui reste différent, c'est qui héberge et configure ce pont : chez PostGraphile, c'est vous ; chez Aurabase, c'est déjà fait.

L'activation est opt-in, par projet, et réservée aux projets moteur Postgres — un projet MongoDB refuse la demande (GRAPHQL_UNSUPPORTED_ENGINE), pg_graphql étant une extension Postgres sans équivalent sur l'autre moteur.

Via la CLI ou en appelant directement le plan de gestion :

# Idempotent : rappeler sur un projet déjà activé ne recrée rien
aura projects graphql-enable <project_id>
# Équivalent HTTP (plan de gestion, JWT console)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

Côté serveur, l'appel enfile un job graphql_enable que le provisionneur exécute en une seule transaction : pose de l'extension, création de la fonction graphql() dans votre schéma, GRANTs vers les rôles applicatifs. Si une étape échoue, tout est annulé — jamais de wrapper posé à moitié, et graphql_enabled ne passe à true qu'après succès complet.

Ça fonctionne aussi bien sur le cluster Postgres partagé que sur une instance CNPG dédiée par projet — deux images Postgres différentes, mais le même mécanisme d'extension. Sur les instances dédiées, l'extension est posée via le manifeste déclaratif de l'opérateur CNPG plutôt qu'en SQL direct — une correction récente. Un cluster dédié tourne sans accès superutilisateur applicatif, et pg_graphql exige justement ce privilège pour son CREATE EXTENSION.

Depuis le Studio, le même flux passe par l'onglet Configuration d'une table. Un bouton y active l'extension au niveau du projet — le même appel HTTP que ci-dessus, avec un polling jusqu'à convergence. Un second contrôle pose ensuite une directive @graphql par table, pour activer ou non totalCount et les champs d'agrégation sur sa collection GraphQL, sans quitter l'éditeur.

Vue commande unique : activation → job de provisioning enfilé (idempotent, no-op si déjà en vol) → transaction DDL (extension, fonction wrapper, GRANTs) → flag graphql_enabled posé seulement après succès complet → requêtes possibles via /rpc/graphql.

La fonction posée par Aurabase est SECURITY INVOKER — comportement par défaut de Postgres, explicité pour qu'un futur refactor ne le change pas par accident. Elle s'exécute avec les privilèges de l'appelant réel (aura_anon, aura_authenticated ou aura_service_role, selon la claim JWT), donc vos policies RLS s'appliquent exactement comme pour une requête REST.

Chez Hasura, l'architecture est différente par construction : le moteur convertit chaque requête GraphQL en une requête SQL contrainte par des règles de permission propres à Hasura. Ces règles sont définies par rôle et par table dans sa propre couche — un système parallèle à la RLS Postgres, pas une délégation vers elle. Deux endroits où auditer les règles d'accès, au lieu d'un seul.

L'introspection ({ __schema { ... } }) reste désactivée par défaut sur chaque projet Aurabase — posture cohérente avec le reste de la plateforme. Elle est activable par schéma via COMMENT ON SCHEMA si un outil comme Apollo Studio ou graphql-codegen en a besoin.

Une fois graphql_enabled à true, aucune route /graphql dédiée n'apparaît sur la gateway. La requête passe par le proxy RPC générique, exactement comme n'importe quelle fonction Postgres appelée depuis le 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 } } } }"}'

La réponse suit la spec GraphQL — { data, errors } — sans enveloppe supplémentaire Aurabase : la gateway détecte que la RPC ciblée est graphql et ne la réemballe pas, contrairement à un RPC ordinaire. Un client GraphQL standard (Apollo, urql, graphql-request) consomme la sortie telle quelle.

Deux réglages sont posés par défaut à l'activation, via une directive @graphql sur le schéma : max_rows: 1000 et inflect_names: true. pg_graphql plafonne par défaut à 10 000 lignes par collection — sans first:, une table volumineuse peut saturer la mémoire. inflect_names donne des noms de type lisibles plutôt que le snake_case brut des tables SQL.

À documenter plutôt qu'à cacher, dans l'esprit de ce blog.

• Pas d'abonnements GraphQL natifs. pg_graphql couvre les requêtes et les mutations, pas les subscriptions temps réel — c'est une limite de l'extension elle-même, pas une omission Aurabase. Le temps réel Aurabase existe, mais via un canal séparé (postgres_changes), pas un pont GraphQL subscriptions.
• Pas d'actions déclaratives à la Hasura. Le modèle « webhook métier branché sur une mutation GraphQL » n'a pas d'équivalent direct — sur Aurabase, cette logique passe par une fonction Postgres ou une Edge Function, pas par une configuration GraphQL dédiée.
• Réservé au moteur Postgres. Un projet MongoDB ne peut pas l'activer — pas de contournement prévu.

Les trois options sont légitimes — le bon choix dépend de ce que vous avez déjà et de ce que vous cherchez à éviter d'opérer.

• pg_graphql sur Aurabase — si votre base et vos policies RLS vivent déjà sur Aurabase et que vous voulez une deuxième façon de l'interroger sans service supplémentaire à surveiller.
• Hasura — si vous fédérez plusieurs sources de données (pas seulement Postgres) derrière un schéma GraphQL unique, ou si PromptQL et son approche agents IA correspondent à votre feuille de route.
• PostGraphile v5 — si vous voulez un contrôle fin sur le schéma généré via son système de plugins, et que vous exploitez déjà un serveur Node.js dans lequel l'intégrer.

Pour la syntaxe complète des requêtes — filtres par type de colonne, tri orderBy, pagination par curseur, mutations insertInto<Table>Collection — voir la documentation officielle de pg_graphql. La documentation GraphQL d'Aurabase, ci-dessous, détaille aussi le cycle complet.