pg_graphql contro Hasura e PostGraphile su Postgres

pg_graphql analizza il tuo schema SQL e genera uno schema GraphQL conforme alla convenzione Relay: <table>Collection, edges, node, filtri per tipo di colonna, impaginazione per cursore. Nessun SDL da scrivere o mantenere a mano: lo schema GraphQL segue il tuo schema Postgres.

Il punto che conta per l'architettura: questo generatore di schemi vive all'interno del database, come una funzione SQL, non come un processo HTTP accanto ad esso. Aurabase aggiunge la versione 1.6.1 dell'estensione (rilasciata il 7 maggio 2026) nella sua immagine Postgres — lo stesso pacchetto ufficiale .deb distribuito da Supabase. Viene installato sia sul cluster condiviso che sulle istanze Postgres dedicate.

Se provieni da Supabase, dove pg_graphql è stato abilitato nativamente da molto tempo, la logica ti sarà familiare. Il nostro confronto dettagliato e la nostra guida alla migrazione coprono il resto dello schema e delle policy RLS, che rimangono gli stessi.

Nessuno dei due concorrenti storici di “GraphQL istantaneo su Postgres” è scomparso. Il loro posizionamento è cambiato e un articolo aggiornato dovrebbe riflettere questo invece di citare la situazione di due anni fa.

Hasura ha pubblicato un post nel giugno 2025 con il titolo esplicito, “From GraphQL to PromptQL: A New Chapter Begins”, firmato dal suo co-fondatore Tanmai Gopal. Il messaggio: l'azienda sta riorientando la propria roadmap su PromptQL, un livello di accesso ai dati progettato per gli agenti AI. Il motore GraphQL non è stato rimosso – la home page di Hasura lo presenta ancora come “testato in battaglia” – ma non è più il messaggio prioritario.

PostGraphile, da parte sua, ha fatto il contrario. La sua versione 5, in sviluppo dal 2023 sotto forma di beta, è diventata generalmente disponibile il 24 marzo 2026, con un nuovo motore di pianificazione delle query chiamato Grafast. Non si tratta di un progetto in esaurimento: l'ultima versione, la 5.1.4, risale al 5 agosto 2026. Il pacchetto npm ha contato 119.230 download nella sola settimana dal 16 al 22 agosto 2026 (registro npm, consultato il 23 agosto 2026).

La differenza che struttura tutto il resto (costi operativi, superficie di attacco, latenza) è dove viene eseguito il motore GraphQL.

Ad essere onesti: PostGraphile delega anche l'autorizzazione a Postgres tramite pgSettings e cambio di ruolo: la RLS nativa non è esclusiva di pg_graphql. Ciò che rimane diverso è chi ospita e configura questo bridge: in PostGraphile sei tu; in Aurabase questo è già stato fatto.

L'attivazione è opzionale, per progetto e riservata ai progetti del motore Postgres: un progetto MongoDB rifiuta la richiesta (GRAPHQL_UNSUPPORTED_ENGINE), essendo pg_graphql un'estensione Postgres senza equivalente sull'altro motore.

Tramite la CLI o chiamando direttamente il piano di gestione:

# Idempotente: richiamare un progetto già attivato non ricrea nulla
aura projects graphql-enable <project_id>

# Equivalente HTTP (piano di gestione, console JWT)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

Lato server, la chiamata esegue un lavoro graphql_enable che il provisioner esegue in un'unica transazione: installazione dell'estensione, creazione della funzione graphql() nel tuo schema, GRANT ai ruoli dell'applicazione. Se un passaggio fallisce, tutto viene annullato, mai un wrapper installato a metà e graphql_enabled passa a true solo dopo il completo successo.

Funziona sia sul cluster Postgres condiviso che su un'istanza CNPG dedicata per progetto: due diverse immagini Postgres, ma lo stesso meccanismo di estensione. Nelle istanze dedicate, l'estensione viene installata tramite il manifest dichiarativo dell'operatore CNPG anziché tramite SQL diretto: una correzione recente. Un cluster dedicato viene eseguito senza accesso come superutente dell'applicazione e pg_graphql richiede esattamente questo privilegio per il suo CREATE EXTENSION.

Da Studio, lo stesso flusso passa attraverso la scheda Configurazione tabella. Un pulsante attiva l'estensione a livello di progetto: la stessa chiamata HTTP di cui sopra, con polling fino alla convergenza. Un secondo controllo imposta quindi una direttiva @graphql per tabella, per attivare o meno totalCount e i campi di aggregazione sulla sua raccolta GraphQL, senza uscire dall'editor.

Visualizzazione comando singolo: attivazione → provisioning del lavoro in thread (idempotente, no-op se già in volo) → transazione DDL (estensione, funzione wrapper, GRANT) → flag graphql_enabled impostato solo dopo il completo successo → richieste possibili tramite /rpc/graphql.

La funzione impostata da Aurabase è SECURITY INVOKER — comportamento predefinito di Postgres, spiegato in modo che un futuro refactoring non lo modifichi per sbaglio. Funziona con i privilegi del chiamante effettivo (aura_anon, aura_authenticated o aura_service_role, a seconda dell'attestazione JWT), quindi i tuoi criteri RLS si applicano esattamente come per una richiesta REST.

In Hasura, l'architettura è diversa per costruzione: il motore converte ogni query GraphQL in una query SQL vincolata da regole di autorizzazione specifiche di Hasura. Queste regole sono definite per ruolo e per tabella nel proprio livello: un sistema parallelo a Postgres RLS, non una delega ad esso. Due posti in cui controllare le regole di accesso, invece di uno solo.

L'introspezione ({ __schema { ... } }) rimane disabilitata per impostazione predefinita su ciascun progetto Aurabase, una postura coerente con il resto della piattaforma. Può essere attivato tramite schema tramite COMMENT ON SCHEMA se uno strumento come Apollo Studio o graphql-codegen ne ha bisogno.

Una volta graphql_enabled a true, sul gateway non viene visualizzata alcuna route /graphql dedicata. La richiesta passa attraverso il generico proxy RPC, proprio come qualsiasi funzione Postgres chiamata dall'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 risposta segue le specifiche GraphQL — { data, errors } — senza il wrapper aggiuntivo di Aurabase: il gateway rileva che l'RPC di destinazione è graphql e non lo riavvolge, a differenza di un normale RPC. Un client GraphQL standard (Apollo, urql, graphql-request) consuma l'output così com'è.

Due impostazioni sono impostate di default al momento dell'attivazione, tramite una direttiva @graphql sullo schema: max_rows: 1000 e inflect_names: true. pg_graphql limita per impostazione predefinita a 10.000 righe per raccolta: senza first:, una tabella di grandi dimensioni può saturare la memoria. inflect_names fornisce nomi di tipo leggibili anziché il semplice snake_case delle tabelle SQL.

Da documentare e non nascondere, nello spirito di questo blog.

• Nessun abbonamento GraphQL nativo. pg_graphql copre query e mutazioni, non in tempo reale subscriptions — questa è una limitazione dell'estensione stessa, non un'omissione di Aurabase. Aurabase in tempo reale esiste, ma attraverso un canale separato (postgres_changes), non un bridge di abbonamenti GraphQL.
• Nessuna azione dichiarativa alla Hasura. Il modello "webhook aziendale connesso a una mutazione GraphQL" non ha un equivalente diretto: su Aurabase, questa logica passa attraverso una funzione Postgres o una funzione Edge, non attraverso una configurazione GraphQL dedicata.
• Riservato al motore Postgres. Un progetto MongoDB non può abilitare questa funzionalità: non è prevista alcuna soluzione alternativa.

Tutte e tre le opzioni sono legittime: la scelta giusta dipende da ciò che già hai e da ciò che stai cercando di evitare.

• pg_graphql su Aurabase — se il tuo database RLS e le tue policy sono già presenti su Aurabase e desideri un secondo modo per interrogarlo senza servizi aggiuntivi da monitorare.
• Hasura: se federa più origini dati (non solo Postgres) dietro un singolo schema GraphQL o se PromptQL e il suo approccio con agente AI si adattano alla tua roadmap.
• PostGraphile v5 — se desideri un controllo preciso sullo schema generato tramite il suo sistema di plug-in e hai già un server Node.js in cui integrarlo.

Per la sintassi completa della query (filtri per tipo di colonna, ordinamento orderBy, impaginazione per cursore, mutazioni insertInto<Table>Collection) consultare la documentazione ufficiale pg_graphql. Anche la documentazione di Aurabase GraphQL, di seguito, descrive in dettaglio il ciclo completo.