Ein Entwicklungsteam soll für ein internes Kundenportal eine Schnittstelle bauen: Kunden sehen ihre Bestellungen, Rechnungen und Lieferungen, der Vertrieb sieht alles. Klassisch bedeutet das Wochen an Routinearbeit. Für jede Tabelle entstehen Endpunkte zum Lesen, Anlegen und Ändern, dazu Prüfungen, wer welche Daten sehen darf, Paginierung, Filter und Tests. Ein Großteil dieses Codes sieht in jedem Projekt fast gleich aus.

Genau an dieser Stelle setzt Hasura an. Die Software liest das Schema einer Datenbank und stellt daraus automatisch eine GraphQL-API bereit, auf Wunsch auch REST-Endpunkte. Zugriffsrechte werden deklarativ festgelegt statt programmiert. Seit dem ersten Erscheinen dieses Beitrags 2021 hat sich das Produkt allerdings stark verändert: Mit Hasura DDN gibt es eine neu entwickelte Generation, die anders aufgebaut ist und nach einem anderen Preismodell abgerechnet wird als die bekannte Version 2. Wer Hasura heute einsetzt oder bereits betreibt, sollte beide Linien auseinanderhalten.

Was Hasura macht und für wen es gedacht ist

Hasura ist eine API-Engine: ein Server, der zwischen Datenbank und Anwendung sitzt. Er übersetzt Anfragen der Frontends in Datenbankabfragen und liefert die Ergebnisse zurück. Anders als bei einem selbst geschriebenen Backend entsteht die Schnittstelle nicht aus Programmcode, sondern aus Konfiguration, in Hasura „Metadaten“ genannt. Darin steht, welche Tabellen freigegeben sind, wie sie zusammenhängen und wer was darf.

Die Grundlage ist GraphQL, eine von Facebook entwickelte Abfragesprache für APIs. Der Client beschreibt darin genau, welche Felder er braucht, und erhält genau diese, auch über mehrere verknüpfte Tabellen hinweg in einer einzigen Anfrage. Wie sich das von klassischen REST-Schnittstellen unterscheidet, erklärt unser Beitrag GraphQL im Vergleich zu REST.

Angesprochen fühlen sollten sich vor allem drei Gruppen: Teams, die schnell ein Frontend auf einer bestehenden Datenbank aufbauen wollen; Unternehmen, die viele Datenquellen hinter einer einheitlichen Schnittstelle bündeln möchten; und Entwicklerinnen und Entwickler, die Prototypen in Tagen statt Wochen brauchen.

So entsteht die API: ein Beispiel

Angenommen, in einer PostgreSQL-Datenbank liegen die Tabellen kunden und bestellungen, verbunden über einen Fremdschlüssel kunde_id. Sobald Hasura mit der Datenbank verbunden ist und die Tabellen freigegeben sind, erkennt die Engine die Beziehung über den Fremdschlüssel und schlägt sie vor; nach der Bestätigung steht sie in der API bereit. Ein Frontend kann dann mit einer einzigen Anfrage die letzten Bestellungen eines Kunden samt Namen abrufen:

query LetzteBestellungen {
  bestellungen(
    where: { status: { _eq: "offen" } }
    order_by: { datum: desc }
    limit: 10
  ) {
    id
    datum
    summe
    kunde {
      name
      ort
    }
  }
}

Filter (where), Sortierung (order_by) und Paginierung (limit, offset) stehen automatisch zur Verfügung, ebenso Mutationen zum Anlegen, Ändern und Löschen. Hasura übersetzt eine solche Anfrage in eine einzige SQL-Abfrage, statt für jeden Kunden eine eigene Abfrage abzusetzen. Damit vermeidet die Engine das sogenannte N+1-Problem, an dem selbst geschriebene GraphQL-Server oft leiden: Für eine Liste von hundert Bestellungen entstehen dort schnell hundert zusätzliche Datenbankabfragen, um die Kundendaten nachzuladen.

Zugriffsrechte als Regel statt als Code

Die eigentliche Stärke liegt in der Rechteverwaltung. Für jede Rolle legen Sie fest, welche Zeilen und Spalten sie lesen oder ändern darf. In Hasura v2 stehen diese Regeln in den Metadaten, etwa so:

# Lesezugriff der Rolle "kunde" auf die Tabelle bestellungen
table:
  name: bestellungen
  schema: public
select_permissions:
  - role: kunde
    permission:
      columns:
        - id
        - datum
        - summe
        - status
      filter:
        kunde_id:
          _eq: X-Hasura-User-Id

Die Regel besagt: Ein angemeldeter Kunde sieht nur die Bestellungen, deren kunde_id seiner eigenen Nutzerkennung entspricht. Woher diese Kennung stammt, entscheidet die Authentifizierung. Hasura meldet selbst keine Nutzer an, sondern übernimmt Rolle und Kennung aus einem JSON Web Token (JWT) eines Identitätsdienstes wie Keycloak, Auth0 oder Microsoft Entra ID oder fragt einen eigenen Webhook. Wie solche Token aufgebaut sind und worauf es bei ihrer Prüfung ankommt, beschreibt unser Beitrag zu tokenbasierter API-Sicherheit mit JWT.

Der Vorteil dieses Ansatzes: Die Regel gilt für jede Anfrage, egal welches Frontend sie stellt. Es gibt keinen vergessenen Endpunkt, in dem die Prüfung fehlt. Der Nachteil: Wer die Metadaten ändert, ändert die Sicherheit. Rechteregeln gehören deshalb in die Versionsverwaltung und in den Review-Prozess wie gewöhnlicher Code.

Geschäftslogik, Ereignisse und REST

Eine API, die nur Tabellen lesen und schreiben kann, reicht selten. Hasura v2 bietet dafür mehrere Erweiterungspunkte:

• Actions verbinden eine GraphQL-Mutation mit einem eigenen HTTP-Dienst. Angenommen, eine Bestellung soll vor dem Speichern gegen das Lager geprüft werden: Diese Logik läuft in einem kleinen Service, Hasura ruft ihn auf und gibt das Ergebnis zurück.
• Event Triggers reagieren auf Änderungen in der Datenbank. Wird eine Bestellung angelegt, ruft Hasura einen Webhook auf, der etwa eine Bestätigungsmail verschickt. Fehlgeschlagene Aufrufe lassen sich auf Wunsch automatisch wiederholen.
• Scheduled Triggers lösen Webhooks zeitgesteuert aus, etwa für einen nächtlichen Bericht.
• Remote Schemas binden bestehende GraphQL-Dienste in die gemeinsame API ein.
• Subscriptions liefern Änderungen in Echtzeit an das Frontend, etwa den Status einer Lieferung.
• RESTified Endpoints machen aus einer gespeicherten GraphQL-Anfrage einen REST-Endpunkt. Das hilft, wenn Partner oder ältere Systeme kein GraphQL sprechen.

Damit lässt sich ein großer Teil eines typischen Backends abdecken. Komplexe Geschäftsprozesse, Rechnungsstellung oder Integrationen mit ERP-Systemen bleiben trotzdem eigener Code, nur eben in kleineren, klar abgegrenzten Diensten.

Hasura v2 und Hasura DDN: zwei Produktlinien

Die Version, die 2021 im Mittelpunkt stand, ist Hasura v2: ein einzelner Server, der als Docker-Container läuft, mit Weboberfläche (Console) und Metadaten in YAML-Dateien. Die Kern-Engine von v2 ist Open Source unter der Apache-2.0-Lizenz. Daneben bot der Hersteller einen gehosteten Dienst (Hasura Cloud) und eine Enterprise Edition mit Zusatzfunktionen wie Caching, erweitertem Monitoring und zusätzlichen Datenbank-Anbindungen an.

2023 kündigte Hasura mit DDN (Data Delivery Network), auch als Hasura v3 bezeichnet, eine grundlegend neu geschriebene Generation an, seit August 2024 ist sie allgemein verfügbar. Die wichtigsten Unterschiede:

Mit dem Supergraph meint der Hersteller eine einheitliche API über mehrere Datenquellen hinweg, etwa PostgreSQL, ein Data Warehouse und einen REST-Dienst, die verschiedene Teams jeweils für ihren Bereich pflegen. Für die Kern-Engine von DDN sieht der Hersteller ebenfalls die Apache-2.0-Lizenz vor, das Preismodell der Hersteller-Plattform unterscheidet sich aber deutlich von v2: Abgerechnet wird nach aktiv genutzten Modellen. Zuletzt hat Hasura zudem mit PromptQL ein Produkt für KI-gestützte Datenabfragen in den Vordergrund gerückt.

Für Bestandsprojekte heißt das: Hasura v2 ist weiterhin verfügbar, ein Umstieg auf DDN ist aber kein Update, sondern eine Migration mit neuem Konfigurationsformat. Vor dem Wechsel sollten Sie prüfen, welche Funktionen Sie tatsächlich nutzen, wie lange der Hersteller v2 noch pflegt und wie sich die Kosten verändern. Für neue Projekte gilt umgekehrt: Wer bewusst auf die quelloffene v2-Engine setzt, sollte wissen, dass die Weiterentwicklung des Herstellers sich auf DDN konzentriert.

Grenzen und Risiken

Der Ansatz „API aus dem Datenbankschema“ ist verlockend, hat aber Nebenwirkungen, die in Projekten regelmäßig unterschätzt werden:

• Enge Kopplung: Wer Tabellen direkt freigibt, macht das Datenbankschema zur öffentlichen Schnittstelle. Jede Umbenennung einer Spalte kann Frontends brechen. Abhilfe schaffen Views oder ein bewusst gestaltetes API-Modell vor den Tabellen.
• Teure Anfragen: GraphQL erlaubt tief verschachtelte Abfragen. Ohne Begrenzungen von Tiefe, Ergebnismenge und Laufzeit kann ein einzelner Client die Datenbank stark belasten.
• Abhängigkeit vom Hersteller: Die Konfiguration ist Hasura-spezifisch. Ein späterer Wechsel zu einem anderen Werkzeug oder zu eigenem Code bedeutet Neuaufbau. Die Produktgeschichte seit 2021 zeigt, dass sich Richtung und Preismodelle ändern können.
• Grenzen der Deklaration: Sobald Rechte von komplexen Geschäftsregeln abhängen, etwa von Freigabestufen oder Vertretungsregelungen, werden die Regeln unübersichtlich. Dann ist eigener Code oft klarer.
• Datenschutz: Weil die API so viel freigibt, wie die Regeln erlauben, sollten personenbezogene Spalten nur gezielt sichtbar sein. Eine automatisch erzeugte API ersetzt nicht die Prüfung, welche Daten ein Frontend wirklich braucht.

Für Frontends mit vielen unterschiedlichen Datenwünschen spielt Hasura seine Stärken aus. Für eine öffentliche Partner-API mit langfristig stabilen Verträgen ist eine bewusst entworfene REST- oder GraphQL-Schnittstelle oft die robustere Wahl.

Was das für Ihr Team bedeutet

Hasura spart dort am meisten Zeit, wo ein großer Teil des Backends aus Datenzugriff mit Rechteprüfung besteht: interne Portale, Verwaltungsoberflächen, Dashboards und mobile Apps auf einer bestehenden Datenbank. Die deklarativen Zugriffsregeln sind dabei ein echter Sicherheitsgewinn, wenn sie sorgfältig gepflegt werden.

Unsere Einschätzung: Für überschaubare Projekte auf PostgreSQL ist Hasura v2 nach wie vor ein produktives Werkzeug, solange das Team die Abhängigkeit vom Hersteller bewusst in Kauf nimmt. Hasura DDN zielt eher auf größere Organisationen, die viele Datenquellen unter einer Schnittstelle zusammenführen wollen. Bevor Sie sich für eine der beiden Linien entscheiden, lohnt ein kurzer Vergleich mit Alternativen, von Datenbank-Plattformen mit eingebauter API bis zum klassisch programmierten Backend.

Wenn Sie eine GraphQL-Schnittstelle planen, ein bestehendes Hasura-Projekt bewerten oder Ihr Team in GraphQL schulen möchten, finden Sie auf unserer Seite zu GraphQL für moderne APIs und Frontends die Angebote von MARTINSFELD. Für die Umsetzung kompletter Schnittstellen und Backends gibt es außerdem unseren Bereich API-Integration und Backend-Entwicklung.

Häufige Fragen zu Hasura

Funktioniert Hasura mit einer bestehenden Datenbank?

Ja. Hasura verbindet sich mit vorhandenen Datenbanken und übernimmt deren Tabellen, Views und Beziehungen. Daten müssen nicht migriert werden. Am besten unterstützt ist PostgreSQL, weitere Datenbanken lassen sich je nach Version und Edition anbinden.

Wie schnell ist Hasura bei komplexen Abfragen?

Weil Hasura eine GraphQL-Anfrage in eine einzige SQL-Abfrage übersetzt, ist es meist schneller als ein naiv programmierter GraphQL-Server. Die Grenze setzt die Datenbank: Fehlende Indizes oder sehr große Ergebnismengen bremsen auch Hasura. Prüfen Sie die erzeugten Abfragen bei Leistungsproblemen deshalb wie jedes andere SQL.

Ist Hasura für große Unternehmen geeignet?

Technisch ja, die Engine lässt sich horizontal skalieren, indem mehrere Instanzen hinter einem Lastverteiler laufen. Wichtiger sind organisatorische Fragen: wer die Metadaten pflegt, wie Änderungen geprüft werden und ob Lizenz- und Betriebsmodell zu den eigenen Vorgaben passen, etwa beim Hosting in der EU.

Brauchen Frontend-Teams spezielle Bibliotheken?

Nein. Jede GraphQL-Bibliothek funktioniert, etwa Apollo Client, urql oder TanStack Query zusammen mit einem einfachen GraphQL-Client. Über RESTified Endpoints kann sogar ein Frontend ohne GraphQL-Kenntnisse auf die Daten zugreifen.