PostgREST vs. Hasura vs. eine benutzerdefinierte API

Hinter der Frage „PostgREST oder Hasura oder benutzerdefinierte API“ verbirgt sich eine nützlichere Frage: Wer schreibt Ihre Geschäftslogik mit welchem Tool und wer verwendet diesen Code in der Produktion? Die drei Architekturen reagieren unterschiedlich, und dieser Unterschied strukturiert alles andere – Sicherheit, Geschwindigkeit der Implementierung, technische Schulden auf lange Sicht.

Keine der drei Säulen ist grundsätzlich besser: Jede verlagert die Arbeit an eine andere Stelle. PostgREST verschiebt es nach SQL, Hasura nach Konfiguration und Webhooks, eine benutzerdefinierte API nach klassischem Anwendungscode.

PostgREST wandelt Ihr Postgres-Schema in eine REST-API um – Filter, Beziehungseinbettung, RPC, RLS gesteuert durch JWT – ohne dass ein Backend geschrieben werden muss. Wir gehen ausführlich auf diesen Bereich in unserem Artikel über seine tatsächliche -Kompatibilität und seine-Alternativen ein; Für diesen Vergleich kommt es darauf an, wo PostgREST aufhört.

PostgREST hat keine Vorstellung von willkürlicher Geschäftslogik. Jede Regel muss in SQL ausgedrückt werden: eine RPC-Funktion, ein Trigger, eine Einschränkung, eine RLS-Richtlinie. Dies ist eine akzeptierte Einschränkung und kein Versehen – das Diagramm bleibt die einzige Quelle der Wahrheit, die jegliche Abweichung zwischen einer Anwendungsschicht und der Basis, der sie dient, verhindert.

Konkret ist es unmöglich, aus einer direkten PostgREST-Anfrage einen Zahlungsdienst eines Drittanbieters anzurufen, eine Bestätigungs-E-Mail zu senden oder einen Score in JavaScript zu berechnen. Diese Logik muss entweder in SQL vorhanden sein (pl/pgsql-Funktion) oder außerhalb ausgelöst werden – ein Trigger, der ein NOTIFY-Ereignis veröffentlicht, das von einem externen Dienst abgehört wird, der nicht mehr PostgREST ist.

In unserem Artikel über GraphQL-Ebenen auf Postgres erfahren Sie, wo die Hasura-Engine ausgeführt wird und wie sich ihre Berechtigungen vom Postgres RLS unterscheiden. Hier geht es um die Geschäftslogik: Wie und wo kann benutzerdefinierter Code in eine von Hasura verwaltete Datenbank eingefügt werden?

Eine -Aktion Hasura stellt eine benutzerdefinierte GraphQL-Mutation oder -Abfrage bereit, unterstützt durch einen HTTP-Webhook, den Sie in der Sprache Ihrer Wahl schreiben. Hasura validiert Eingaben gemäß dem deklarierten Schema, ruft Ihren Webhook auf und gibt dann seine Antwort an den Client zurück. Es ist das Tor zu jeder Logik, die über CRUD hinausgeht: Aufruf eines Zahlungsanbieters, komplexe Berechnung, mehrstufige Orchestrierung.

Die -Ereignisauslöser folgen der entgegengesetzten Richtung: Ein Einfügen, Aktualisieren oder Löschen einer Tabelle löst asynchron und mit automatischem Neustart im Fehlerfall einen Webhook aus. Dies ist der Mechanismus, den die meisten Hasura-Integrationen verwenden, um einen Drittanbieterdienst (Abrechnung, Transaktions-E-Mail, Suchmaschine) zu synchronisieren, ohne diesen Code an die ursprüngliche Kundenanfrage zu koppeln.

Hasura kann auch eine bereits geschriebene GraphQL-Abfrage als typische REST-Route mit einem benannten Pfad und Parametern bereitstellen – seinen RESTified-Endpunkten, in der Terminologie seiner eigenen Dokumentation. Nützlich, wenn Ihr Frontend-Team lieber REST nutzt, ohne auf die zugrunde liegende GraphQL-Berechtigungs-Engine zu verzichten.

Kontexterinnerung, entwickelt in unserem speziellen Artikel: Hasura hat seine Kommunikation seit Juni 2025 neu auf PromptQL ausgerichtet, eine für KI-Agenten entwickelte Ebene – ohne die GraphQL-Engine zu entfernen, die auf ihrer offiziellen Website immer noch als „kampferprobt“ dargestellt wird.

Eine handgeschriebene API kennt per Definition keine Grenzen: jede Geschäftslogik, in jeder Sprache, mit allen Abhängigkeiten. Es ist außerdem die einzige der drei Optionen, bei der nichts für Sie generiert wird – jede Route, jede Validierung, jede Verbindung zur Datenbank ist Code, der Ihnen gehört und den Sie pflegen müssen.

// Der Filter, die Sortierung und die Beziehungseinbettung werden von Hand geschrieben,
// Nur für diese Route – wiederholen Sie den Vorgang für jede API-Ressource
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

Was dieses Modell im Austausch für manuelle Arbeit bietet: vollständige Kontrolle über Fehler und zurückgegebene HTTP-Codes, klassische Testbarkeit (Handler, keine deklarative Konfiguration) und kein neues DSL, das für ein Team erlernt werden muss, das seine Sprache bereits beherrscht.

Was es im Gegenzug kostet: CRUD, Paginierung und Filter, die für jede Ressource manuell geschrieben und verwaltet werden müssen; Authentifizierung und Autorisierung zur eigenen Implementierung und Prüfung, ohne automatisch geerbtes RLS; das Risiko von N+1-Abfragen, wenn jede verschachtelte Beziehung ohne Disziplin ihre eigene Postgres-Abfrage auslöst; und API-Dokumentation, die manuell gepflegt oder über einen Drittanbieter-Generator integriert werden kann.

Was die Rohleistung betrifft, ist die Frage „Ist Node.js langsamer als Rust?“ ein eigenständiges Thema – unser Artikel über Rust vs. Node.js-Latenz behandelt sie ausführlich, wobei die Methodik auf unserer -Benchmark-Methodik-Seiteim Upstream erklärt wird. Eine benutzerdefinierte API hat das gleiche Leistungsprofil wie jeder HTTP-Dienst, den Sie bereits verwenden, und ist aufgrund ihrer Konstruktion weder besser noch schlechter. Um genau zu wissen, wo PostgREST gesättigt ist und ab welchem ​​Punkt eine benutzerdefinierte Ebene erforderlich ist, lesen Sie unseren Artikel über die tatsächlichen Grenzen von PostgREST in der Produktion.

Über die Architektur hinaus fallen bei der Auswahl am häufigsten vier Kriterien auf: Geschwindigkeit der Implementierung, echte geschäftliche Flexibilität, langfristige technische Schulden und der typische Anwendungsfall, bei dem jede Option am komfortabelsten ist.

Bei einem Aurabase-Postgres-Engine-Projekt wird die CRUD-Ebene bereits durch eine tatsächliche PostgREST-Instanz abgedeckt, nicht durch eine ungefähre Neuimplementierung. Die Frage, die für diesen Vergleich offen bleibt: Wo soll geschrieben werden, was über das CRUD hinausgeht?

Es gibt zwei Wege, die sich nicht gegenseitig ausschließen. Die erste: eine in RPC verfügbar gemachte SQL-Funktion für jede Logik, deren Ausdruck in SQL sinnvoll bleibt – Gesamtberechnung, Kreuzvalidierung zwischen mehreren Tabellen, kaskadierende Aktualisierungen in einer einzigen Transaktion.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

Der zweite Weg: Edge Functions, für alles, was über die SQL-Domäne hinausgeht – Aufruf einer Zahlungs-API, Senden einer E-Mail, Berechnen einer Einbettung. Bei Aurabase führen zwei Wege dorthin: der Studio-Editor, der Deno-Code (TypeScript) genau wie auf Supabase ausführt, und die aura functions deployCLI, die einen separaten Pfad für in Rust geschriebene und in WASM kompilierte Funktionen anstrebt – detailliert in unserer einheitlichen Rust-Architektur. Keiner der Pfade erfordert das Hosten eines separaten Knotenservers, im Gegensatz zur reinen „benutzerdefinierten API“-Option in diesem Artikel, bei der dieser Server vollständig in Ihrer Verantwortung liegt.

Diese Verteilung ist kein wackeliger Kompromiss zwischen den drei hier verglichenen Modellen: Sie ist im wahrsten Sinne des Wortes PostgREST für CRUD, ein Baustein in der Nähe von Hasura Actions für Ereignislogik über RPC und Trigger sowie Edge Functions, die den Betrieb eines vollständigen Anwendungsservers vermeiden – ohne jemals eine binäre Wahl zwischen „alle PostgREST“ und „alle benutzerdefiniert“ zu erzwingen.

Vier Situationen kommen am häufigsten vor. Die richtige Wahl hängt hauptsächlich davon ab, was Ihre Geschäftslogik erfordert, und nicht von der Beliebtheit eines Tools.

• Ihr Schema ist stabil und Ihre Geschäftslogik ist in SQL. Selbstgehostetes PostgREST oder nativ integriert (Aurabase, Supabase) reicht aus: Es muss nichts mehr gehostet werden, und das Schema bleibt die einzige Quelle der Wahrheit.
• Sie möchten mehrere Datenquellen zusammenführen oder Ihre Roadmap ist darauf ausgerichtet, dass KI-Agenten Ihre Daten konsumieren. Hasura passt mit seiner PromptQL-Schicht besser zu diesem Terrain.
• Ihr Produkt verfügt über umfangreiche Geschäftslogik, zahlreiche Integrationen von Drittanbietern und ein Team, das bereits mit einer Anwendungssprache ausgestattet ist. Eine benutzerdefinierte API bleibt die direkteste Wahl, allerdings auf Kosten des Schreibens und der langfristigen Wartung.
• Sie möchten selbst generiertes CRUD, ohne echten Platz für Geschäftslogik (RPC, Edge-Funktionen) aufzugeben, ohne einen weiteren Anwendungsdienst zur Ausnutzung zu stapeln. Dies ist der Winkel, der in diesem Vergleich dokumentiert ist, angewendet auf Aurabase, vorheriger Abschnitt.