pg_graphql vs Hasura und PostGraphile auf Postgres

pg_graphql prüft Ihr SQL-Schema und generiert ein GraphQL-Schema, das der Relay-Konvention entspricht – <table>Collection, edges, node, Filter nach Spaltentyp, Paginierung nach Cursor. Kein SDL, das manuell geschrieben oder verwaltet werden muss: Das GraphQL-Schema folgt Ihrem Postgres-Schema.

Der Punkt, der für die Architektur wichtig ist: Dieser Schemagenerator lebt in der Datenbank, als SQL-Funktion, nicht als daneben liegender HTTP-Prozess. Aurabase pinnt die 1.6.1-Version der Erweiterung (veröffentlicht am 7. Mai 2026) in seinem Postgres-Image – dem gleichen offiziellen .deb-Paket, das von Supabase vertrieben wird. Es wird sowohl auf dem gemeinsam genutzten Cluster als auch auf den dedizierten Postgres-Instanzen installiert.

Wenn Sie von Supabase kommen, wo pg_graphql schon seit langem nativ aktiviert ist, wird Ihnen die Logik bekannt sein. Unser detaillierter -Vergleich und unser -Migrationsleitfaden decken den Rest des RLS-Schemas und der Richtlinien ab, die gleich bleiben.

Keiner der beiden historischen Konkurrenten von „Instant GraphQL on Postgres“ ist verschwunden. Ihre Positionierung hat sich verändert, und ein aktualisierter Artikel sollte dies widerspiegeln, anstatt den Stand von vor zwei Jahren zu zitieren.

Hasura veröffentlichte im Juni 2025 einen Beitrag mit dem expliziten Titel „Von GraphQL zu PromptQL: Ein neues Kapitel beginnt“, unterzeichnet von seinem Mitbegründer Tanmai Gopal. Die Botschaft: Das Unternehmen konzentriert seine Roadmap neu auf PromptQL, eine Datenzugriffsschicht, die für KI-Agenten entwickelt wurde. Die GraphQL-Engine wird nicht entfernt – Hasuras Homepage präsentiert sie immer noch als „kampferprobt“ – aber sie ist nicht mehr die vorrangige Nachricht.

PostGraphilehat seinerseits das Gegenteil bewirkt. Die Version 5, die sich seit 2023 in Form von Betas in der Entwicklung befindet, wurde am 24. März 2026 mit einer neuen Abfrageplanungs-Engine namens Grafast allgemein verfügbar. Dies ist kein Projekt, dem die Puste ausgeht: Die letzte Version, 5.1.4, stammt vom 5. August 2026. Das npm-Paket zählte allein in der Woche vom 16. bis 22. August 2026 119.230 Downloads (npm-Registrierung, konsultiert am 23. August 2026).

Der Unterschied, der alles andere strukturiert – Betriebskosten, Angriffsfläche, Latenz – besteht darin, wo die GraphQL-Engine ausgeführt wird.

Um ehrlich zu sein: PostGraphile delegiert die Autorisierung auch über pgSettings und Rollenwechsel an Postgres – natives RLS ist nicht exklusiv für pg_graphql. Der Unterschied bleibt, wer diese Brücke hostet und konfiguriert: Bei PostGraphile sind Sie es; Bei Aurabase ist dies bereits geschehen.

Die Aktivierung ist pro Projekt optional und für Postgres-Engine-Projekte reserviert – ein MongoDB-Projekt lehnt die Anfrage ab (GRAPHQL_UNSUPPORTED_ENGINE), da pg_graphql eine Postgres-Erweiterung ohne Äquivalent auf der anderen Engine ist.

Über die CLI oder durch direkten Aufruf des Managementplans:

# Idempotent: Durch das Zurückrufen eines bereits aktivierten Projekts wird nichts neu erstellt
aura projects graphql-enable <project_id>

# HTTP-Äquivalent (Verwaltungsebene, JWT-Konsole)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

Auf der Serverseite führt der Aufruf einen graphql_enable-Job aus, den der Provisioner in einer einzigen Transaktion ausführt: Installation der Erweiterung, Erstellung der Funktion graphql() in Ihrem Schema, GRANTs für die Anwendungsrollen. Wenn ein Schritt fehlschlägt, wird alles abgebrochen – es wird niemals ein Wrapper zur Hälfte installiert, und graphql_enabled wechselt erst nach vollständigem Erfolg zu true.

Es funktioniert sowohl auf dem gemeinsam genutzten Postgres-Cluster als auch auf einer dedizierten CNPG-Instanz pro Projekt – zwei verschiedene Postgres-Images, aber der gleiche Erweiterungsmechanismus. Auf dedizierten Instanzen wird die Erweiterung über das deklarative Manifest des CNPG-Operators und nicht über direktes SQL installiert – eine aktuelle Korrektur. Ein dedizierter Cluster läuft ohne Anwendungs-Superuser-Zugriff und pg_graphql benötigt genau dieses Privileg für seinen CREATE EXTENSION.

Von Studio aus erfolgt derselbe Ablauf über die Registerkarte „Tabellenkonfiguration“. Dort aktiviert ein Button die Erweiterung auf Projektebene – derselbe HTTP-Aufruf wie oben, mit Polling bis zur Konvergenz. Ein zweites Steuerelement legt dann eine @graphql-Direktive pro Tabelle fest, um totalCount und die Aggregationsfelder in seiner GraphQL-Sammlung zu aktivieren oder nicht, ohne den Editor zu verlassen.

Einzelbefehlsansicht: Aktivierung → Bereitstellungsjob mit Thread (idempotent, No-Op, wenn bereits im Flug) → DDL-Transaktion (Erweiterung, Wrapper-Funktion, GRANTs) → Flag graphql_enabled erst nach vollständigem Erfolg gesetzt → Anfragen über /rpc/graphqlmöglich.

Die von Aurabase festgelegte Funktion ist SECURITY INVOKER – Standardverhalten von Postgres, erklärt, damit ein zukünftiger Refactor es nicht versehentlich ändert. Es läuft mit den Berechtigungen des tatsächlichen Aufrufers (aura_anon, aura_authenticated oder aura_service_role, abhängig vom JWT-Anspruch), sodass Ihre RLS-Richtlinien genau wie für eine REST-Anfrage gelten.

Bei Hasura unterscheidet sich die Architektur konstruktionsbedingt: Die Engine wandelt jede GraphQL-Abfrage in eine SQL-Abfrage um, die durch für Hasura spezifische Berechtigungsregeln eingeschränkt ist. Diese Regeln werden pro Rolle und pro Tabelle in einer eigenen Ebene definiert – ein paralleles System zum Postgres RLS, keine Delegation an dieses. Zwei Orte zum Überwachen von Zugriffsregeln statt nur einem.

Introspection ({ __schema { ... } }) bleibt bei jedem Aurabase-Projekt standardmäßig deaktiviert – eine Haltung, die mit dem Rest der Plattform konsistent ist. Es kann per Schema über COMMENT ON SCHEMA aktiviert werden, wenn ein Tool wie Apollo Studio oder graphql-codegen es benötigt.

Sobald graphql_enabled bis true, wird auf dem Gateway keine dedizierte /graphql-Route angezeigt. Die Anfrage durchläuft den generischen RPC-Proxy , genau wie jede vom SDK aufgerufene Postgres-Funktion.

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 } } } }"}'

Die Antwort folgt der GraphQL-Spezifikation – { data, errors } – ohne zusätzliches Aurabase-Wrapping: Das Gateway erkennt, dass der Ziel-RPC graphql ist und umschließt ihn im Gegensatz zu einem gewöhnlichen RPC nicht erneut. Ein Standard-GraphQL-Client (Apollo, urql, graphql-request) konsumiert die Ausgabe unverändert.

Bei der Aktivierung werden standardmäßig zwei Einstellungen über eine @graphql-Direktive im Diagramm festgelegt: max_rows: 1000 und inflect_names: true. pg_graphql ist standardmäßig auf 10.000 Zeilen pro Sammlung begrenzt – ohne first:kann eine große Tabelle den Speicher überlasten. inflect_names liefert lesbare Typnamen anstelle des rohen Snake_case von SQL-Tabellen.

Im Sinne dieses Blogs soll es dokumentiert und nicht verborgen werden.

• Keine nativen GraphQL-Abonnements. pg_graphql deckt Abfragen und Mutationen ab, nicht Echtzeit subscriptions – dies ist eine Einschränkung der Erweiterung selbst und kein Versäumnis von Aurabase. Echtzeit-Aurabase existiert, jedoch über einen separaten Kanal (postgres_changes), nicht über eine GraphQL-Abonnementbrücke.
• Keine Feststellungsklagen à la Hasura. Das Modell „Business Webhook verbunden mit einer GraphQL-Mutation“ hat kein direktes Äquivalent – ​​auf Aurabase durchläuft diese Logik eine Postgres-Funktion oder eine Edge-Funktion, nicht eine dedizierte GraphQL-Konfiguration.
• Reserviert für die Postgres-Engine. Ein MongoDB-Projekt kann dies nicht aktivieren – keine Problemumgehung vorgesehen.

Alle drei Optionen sind legitim – die richtige Wahl hängt davon ab, was Sie bereits haben und was Sie vermeiden möchten.

• pg_graphql auf Aurabase – wenn Ihre RLS-Datenbank und Richtlinien bereits auf Aurabase leben und Sie eine zweite Möglichkeit zur Abfrage ohne zusätzliche zu überwachende Dienste wünschen.
• Hasura – wenn Sie mehrere Datenquellen (nicht nur Postgres) hinter einem einzelnen GraphQL-Schema zusammenfassen oder wenn PromptQL und sein KI-Agent-Ansatz zu Ihrer Roadmap passen.
• PostGraphile v5 – wenn Sie eine genaue Kontrolle über das über das Plugin-System generierte Schema wünschen und bereits einen Node.js-Server ausführen, in den Sie es integrieren können.

Die vollständige Abfragesyntax – Filter nach Spaltentyp, orderBySortierung, Paginierung nach Cursor, insertInto<Table>Collection Mutationen – finden Sie in der offiziellen pg_graphqlDokumentation. In der Aurabase GraphQL-Dokumentation unten wird auch der gesamte Zyklus detailliert beschrieben.