PostgREST-Kompatibilität: Was es abdeckt und Alternativen

PostgREST ist ein autonomer Webserver, der eine vorhandene PostgreSQL-Datenbank direkt aus ihrem Schema in eine REST-API umwandelt. Es muss keine Anwendungsschicht geschrieben werden: Tabellen, Ansichten und Funktionen werden zu Routen, und SQL-Berechtigungen – Rollen, RLS-Richtlinien – werden zur Autorisierungsschicht.

Konkret deckt PostgREST fünf Funktionen ab, die in fast allen Auswertungen auftauchen:

• Horizontale Filterung – etwa dreißig Operatoren (eq, gt, like, ilike, in, is, cs, ov, fts...) direkt in der Abfragezeichenfolge.
• Vertikale Filterung und Einbettung – ?select= projiziert Spalten und bettet Beziehungen über Fremdschlüssel ein, zum Beispiel customer:customers(email).
• RPC – ein POST /rpc/{fonction} ruft direkt eine SQL-Funktion auf, die zu einem Endpunkt wird.
• RLS gesteuert durch JWT – PostgREST wechselt die aktive Postgres-Rolle entsprechend dem empfangenen Token (SET LOCAL ROLE), sodass Ihre Richtlinien unverändert gelten, ohne doppelte Autorisierungslogik auf der Anwendungsseite.
• Selbstgeneriertes OpenAPI – die Spezifikation wird aus dem offengelegten Schema abgeleitet, ohne dass eine Datei manuell verwaltet werden muss.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

Eine einzige HTTP-Anfrage filtert bezahlte Bestellungen, bettet die E-Mail des Kunden über einen Fremdschlüssel ein und sortiert nach Datum – ohne dass eine einzige Route von Hand geschrieben werden muss.

Der RPC folgt derselben Logik: Eine bereits in Ihrer Datenbank geschriebene SQL-Funktion wird zu einem POST-Endpunkt, dessen Argumente in JSON übergeben werden.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Dieses Prinzip – das Postgres-Schema ist die einzige Wahrheitsquelle der API – macht PostgREST vorhersehbar: Jede Verhaltensänderung durchläuft eine SQL-Migration und niemals eine separate Anwendungsschicht, die vom tatsächlichen Schema abgeleitet werden könnte. Das Projekt ist Open Source, entwickelt auf GitHub, unabhängig von einem bestimmten BaaS-Anbieter.

PostgREST löst die CRUD-Schicht auf. Der Rest eines Anwendungs-Backends wird dadurch nicht aufgelöst. Bei Teams, die es alleine anwenden, treten systematisch vier Mängel auf.

• Authentifizierung – keine JWT-Ausgabe oder integrierte Benutzerverwaltung. Sie müssen es in SQL erstellen oder an einen externen Dienst delegieren.
• Dateispeicherung – keine. Ein S3-Bucket oder ein gleichwertiges Gerät muss weiterhin separat angeschlossen werden.
• Echtzeit – PostgREST antwortet auf einmalige HTTP-Anfragen, es pusht keine Ereignisse.
• Verbindungspooler – PostgREST selbst stellt eine Verbindung zu Postgres her, integriert jedoch keine erweiterten Pooler. Im großen Maßstab wird die Verwaltung zu einer eigenständigen Betriebsentscheidung: Ein Pooler im klassischen Transaktionsmodus steht im Konflikt mit dem PostgREST-Schema-Neulademechanismus (siehe unten, wie Aurabase diesen Kompromiss löst).

Eine praktische Konsequenz muss klar zum Ausdruck gebracht werden: Ohne Authentifizierung werden Ihre RLS-Richtlinien zur einzigen Sicherheitsgrenze zwischen einem anonymen Kunden und Ihren Daten. Eine schlecht geschriebene Richtlinie für die Rolle anon wird nicht durch eine zusätzliche Anwendungsschicht überholt – es gibt keine.

Bei einem Aurabase-Postgres-Engine-Projekt – der Standard-Engine – leitet das Gateway jede CRUD-Anfrage direkt an eine PostgREST v12.2.8-Instanz weiter, die diesem Projekt gewidmet ist, zwei Replikate, die sich gemeinsam mit dem Postgres-Cluster des Mandanten befinden. Dabei handelt es sich nicht um eine ungefähre Kompatibilität: Es handelt sich um die PostgREST-Upstream-Binärdatei selbst, mit denselben Operatoren, derselben Einbettung, demselben RPC und demselben RLS, das von JWT gesteuert wird.

Bei einem MongoDB-Engine-Projekt sieht die Sache anders aus. MongoDB hat kein Äquivalent zu PostgREST: Diese Anfragen werden an einen internen Aurabase-Dienst weitergeleitet, der eine Teilmenge derselben Konventionen neu implementiert – identische Operatornamen, ?select=-Syntax mit Einbettung, Prefer- und Content-Range-Header – jedoch auf einer Dokument-Engine, nicht auf einer relationalen. Diese Ebene hat ihre eigenen Einschränkungen: Eine in der von einer Mutation zurückgegebenen Darstellung angeforderte Einbettung wird explizit abgelehnt und nicht stillschweigend ignoriert, und es gibt keine RPC-Route, die SQL-Funktionen entspricht.

Ein technisches Detail steht im Gegensatz zur Intuition: Jede dedizierte PostgREST-Instanz bleibt direkt mit dem primären Postgres verbunden, ohne den für diesen Mandanten bereitgestellten PgBouncer-Pooler zu durchlaufen. Vermuteter Grund: Der Transaktions-Pooling-Modus würde das Neuladen des PostgREST-Schemas unterbrechen, das auf LISTEN/NOTIFY basiert – einer dauerhaften Verbindung, die nicht mit einem Pool kompatibel ist, der die Verbindung für jede Transaktion wiederverwendet.

Ein weiteres nützliches Detail in der Produktion: Ein inaktives Projekt kann pausiert werden, um Ressourcen zu sparen. Die erste Anfrage an ein schlafendes Projekt löst dessen Aufwecken aus und empfängt ein 503 mit einer Wiederholungsverzögerung, der Zeit, die die dedizierte PostgREST-Instanz benötigt, um wieder hochzufahren – ein angenommener Kompromiss zwischen Kosten und kalter Latenz, kein versteckter Vorfall.

PostgREST hat einen klaren Zweck: Das Postgres-Schema ist die Quelle der Wahrheit, und das Team möchte vermeiden, eine CRUD-Ebene von Hand zu schreiben. Abgesehen von diesem speziellen Fall gibt es mehrere Familien von Alternativen, je nachdem, was Sie hinzufügen möchten – von gar nichts (einfach selbst gehostet) bis hin zu einem kompletten, gebrauchsfertigen Backend.

Die folgende Tabelle vergleicht, was jede Option nativ abdeckt und was sie explizit Ihnen überlässt – ohne Werturteil über die von jedem Projekt gewählte Architektur.

Ein Punkt, der bei der Wahl von „selbst gehostet“ oft unterschätzt wird: PostgREST selbst lässt sich weiterhin leicht ausführen, aber der Produktionsbetrieb (Versionsaktualisierung, Hochverfügbarkeit, Verbindung mit einem Pooler, Überwachung) liegt vollständig in Ihrer Verantwortung – es ist diese Betriebsarbeit, nicht die Software, die verwaltete Plattformen absorbieren.

Für einen detaillierten Vergleich zwischen GraphQL-Ansätzen – pg_graphql, Hasura und PostGraphile – siehe , unseren Artikel über die GraphQL-API auf Postgres.

Vier Situationen kommen am häufigsten vor. Die richtige Wahl hängt vor allem davon ab, was Sie bereit sind, selbst zusammenzubauen und zu warten.

• Sie möchten lediglich eine REST-API über ein vorhandenes Postgres-Schema, sonst nichts. Selbstgehostetes PostgREST reicht aus: Es macht genau das, was es tut, und es muss nichts anderes installiert werden.
• Sie benötigen zusätzliche Authentifizierung, Speicher und Echtzeit und sind bereit, mehrere Dienste zusammenzustellen. Supabase oder PostgREST zusammen mit Ihrem eigenen Anwendungsstapel erfüllt diesen Bedarf.
• Sie bevorzugen GraphQL gegenüber REST. Hasura oder PostGraphile decken diesen Bereich ab – eine andere architektonische Wahl, kein direkter Ersatz für PostgREST.
• Sie möchten ein vollständiges Postgres-Backend, ohne mehrere separate Dienste zusammenzufügen. Dies ist der Aspekt, den unsere einheitliche Rust-Architektur dokumentiert: echtes PostgREST für die CRUD-Schicht, nativ umgeben von Authentifizierungs-, Speicher-, Echtzeit- und Edge-Funktionen.