PostgREST versus Hasura versus een aangepaste API

De vraag “PostgREST of Hasura of aangepaste API” verbergt een nuttiger vraag: wie schrijft uw bedrijfslogica, met welke tool, en wie gebruikt deze code in de productie? De drie architecturen reageren verschillend, en dit verschil structureert al het andere: veiligheid, snelheid van implementatie, technische schulden op de lange termijn.

Geen van de drie kolommen is strikt genomen beter: elke kolom verplaatst het werk naar een andere plek. PostgREST verplaatst het naar SQL, Hasura naar configuratie en webhooks, een aangepaste API naar klassieke applicatiecode.

PostgREST transformeert uw Postgres-schema in een REST API – filters, relatie-inbedding, RPC, RLS aangestuurd door JWT – zonder dat u een backend hoeft te schrijven. We gaan dieper in op deze reikwijdte in ons artikel over de echte -compatibiliteit en de-alternatieven; wat voor deze vergelijking van belang is, is waar PostgREST stopt.

PostgREST heeft geen notie van willekeurige bedrijfslogica. Elke regel moet in SQL worden uitgedrukt: een RPC-functie, een trigger, een beperking, een RLS-beleid. Dit is een geaccepteerde beperking, geen vergissing: het diagram blijft de enige bron van waarheid, waardoor elke afwijking tussen een applicatielaag en de basis die deze bedient wordt geëlimineerd.

Concreet is het onmogelijk om vanuit een directe PostgREST-aanvraag een betalingsdienst van derden te bellen, een bevestigingsmail te sturen of een score in JavaScript te berekenen. Deze logica moet óf in SQL voorkomen (pl/pgsql-functie), óf daarbuiten worden geactiveerd - een trigger die een NOTIFY-gebeurtenis publiceert, waarnaar wordt geluisterd door een externe service die niet langer PostgREST is.

Ons artikel over GraphQL-lagen op Postgres beschrijft waar de Hasura-engine draait en hoe de machtigingen verschillen van de Postgres RLS. Hier is de invalshoek die van de bedrijfslogica: hoe je aangepaste code kunt inpluggen in een database die wordt beheerd door Hasura, en waar.

Een Actie Hasura geeft een aangepaste GraphQL-mutatie of -query weer, ondersteund door een HTTP-webhook die u schrijft in de taal van uw keuze. Hasura valideert de invoer volgens het aangegeven schema, roept uw ​​webhook aan en stuurt vervolgens het antwoord terug naar de client. Het is de toegangspoort tot elke logica die verder gaat dan CRUD: oproep aan een betalingsprovider, complexe berekeningen, orkestratie in meerdere stappen.

De Event Triggers volgen de tegenovergestelde richting: een invoeging, een update of een verwijdering van een tabel activeert een webhook, asynchroon en met automatische herstart in geval van een storing. Dit is het mechanisme dat de meeste Hasura-integraties gebruiken om een ​​service van derden (facturering, transactionele e-mail, zoekmachine) te synchroniseren zonder deze code te koppelen aan het initiële klantverzoek.

Hasura kan ook een reeds geschreven GraphQL-query weergeven als een typische REST-route, met een benoemd pad en parameters: de RESTified-eindpunten, in de terminologie van zijn eigen documentatie. Handig als uw frontendteam liever REST gebruikt, zonder de onderliggende GraphQL-machtigingsengine op te geven.

Contextherinnering, ontwikkeld in ons speciale artikel: Hasura heeft zijn communicatie sinds juni 2025 geheroriënteerd op PromptQL, een laag ontworpen voor AI-agenten – zonder de GraphQL-engine te verwijderen, die op zijn officiële website nog steeds als “getest” wordt gepresenteerd.

Een handgeschreven API kent per definitie geen grenzen: welke bedrijfslogica dan ook, in welke taal dan ook, met welke afhankelijkheden dan ook. Het is ook de enige van de drie opties waarbij niets voor u wordt gegenereerd: elke route, elke validatie, elke verbinding met de database is code waarvan u de eigenaar bent en die u moet onderhouden.

// Het filter, de sortering en het inbedden van relaties zijn met de hand geschreven,
// alleen voor deze route: herhaal dit voor elke API-bron
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)
});

Wat dit model biedt, in ruil voor handmatig werk: volledige controle over fouten en geretourneerde HTTP-codes, klassieke testbaarheid (handlers, geen declaratieve configuratie) en geen nieuwe DSL om te leren voor een team dat de taal al beheerst.

Wat het kost, in ruil: CRUD, paginering en filters om voor elke bron handmatig te schrijven en te onderhouden; authenticatie en autorisatie om zelf te implementeren en te controleren, zonder automatisch overgenomen RLS; het risico van N+1-query's als elke geneste relatie zonder discipline zijn eigen Postgres-query activeert; en API-documentatie die handmatig moet worden onderhouden, of via een externe generator kan worden geïntegreerd.

Wat de ruwe prestaties betreft, is de vraag “Is Node.js langzamer dan Rust” een onderwerp op zich: ons artikel over Rust versus Node.js latentie behandelt dit in detail, met de methodologie die upstream wordt verklaard op onze benchmarkmethodologiepagina. Een aangepaste API heeft hetzelfde prestatieprofiel als elke HTTP-service die u al gebruikt, noch beter noch slechter qua constructie. Om precies te weten waar PostgREST verzadigd raakt en op welk punt een aangepaste laag nodig wordt, zie ons artikel over de echte grenzen van PostgREST in productie.

Naast de architectuur komen bij de keuze meestal vier criteria naar voren: snelheid van implementatie, echte bedrijfsflexibiliteit, technische schulden op de lange termijn en de typische gebruikssituatie waarbij elke optie het meest comfortabel is.

Op een Aurabase Postgres-engineproject wordt de CRUD-laag al bedekt door een daadwerkelijke PostgREST-instantie, en niet door een geschatte herimplementatie. De vraag die open blijft bij deze vergelijking: waar moet ik schrijven wat verder gaat dan de CRUD?

Er bestaan twee paden, die elkaar niet uitsluiten. De eerste: een SQL-functie die in RPC wordt weergegeven, voor elke logica die redelijkerwijs in SQL kan worden uitgedrukt: berekening van een totaal, kruisvalidatie tussen verschillende tabellen, trapsgewijze updates in één enkele transactie.

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

De tweede manier: Edge Functions, voor alles wat verder gaat dan het SQL-domein: het aanroepen van een betalings-API, het verzenden van een e-mail, het berekenen van een inbedding. Bij Aurabase leiden twee paden daar naartoe: de Studio-editor, die Deno (TypeScript)-code precies zo uitvoert als op Supabase, en de aura functions deployCLI, die streeft naar een apart pad voor functies geschreven in Rust en gecompileerd in WASM - gedetailleerd in onze verenigde Rust-architectuur. Voor geen van beide paden is het hosten van een afzonderlijke Node-server vereist, in tegenstelling tot de pure “aangepaste API”-optie in dit artikel, waarbij die server volledig uw verantwoordelijkheid is.

Deze distributie is geen wankel compromis tussen de drie hier vergeleken modellen: het is letterlijk PostgREST voor CRUD, een steen die dicht bij Hasura Actions ligt voor gebeurtenislogica via RPC en triggers, en Edge Functions die de werking van een volledige applicatieserver vermijden - zonder ooit een binaire keuze tussen "alle PostgREST" en "allemaal op maat" te forceren.

Vier situaties komen het vaakst voor. De juiste keuze hangt vooral af van wat uw bedrijfslogica vereist, en niet van de populariteit van een tool.

• Uw schema is stabiel en uw bedrijfslogica bevindt zich in SQL. Zelf-gehoste PostgREST, of native geïntegreerd (Aurabase, Supabase), is voldoende: er hoeft niets meer te worden gehost en het schema blijft de enige bron van waarheid.
• U wilt meerdere gegevensbronnen samenbrengen, of uw routekaart is gericht op AI-agenten die uw gegevens gebruiken. Hasura past met zijn PromptQL-laag beter in dit terrein.
• Uw product beschikt over rijke bedrijfslogica, talrijke integraties van derden en een team dat al is uitgerust met een applicatietaal. Een aangepaste API blijft de meest directe keuze, ten koste van het schrijven en onderhouden ervan in de loop van de tijd.
• Je wilt zelf gegenereerde CRUD zonder echte ruimte op te geven voor bedrijfslogica (RPC, Edge Functions), zonder nog een applicatieservice op te stapelen om te exploiteren. Dit is de hoek die is gedocumenteerd in deze vergelijking, toegepast op Aurabase, vorige sectie.