PostgREST-compatibiliteit: wat het omvat, en alternatieven

PostgREST is een autonome webserver die een bestaande PostgreSQL-database rechtstreeks vanuit het schema omzet in een REST API. Geen applicatielaag om te schrijven: tabellen, views en functies worden routes, en SQL-machtigingen (rollen, RLS-beleid) worden de autorisatielaag.

Concreet omvat PostgREST vijf mogelijkheden die in bijna alle evaluaties naar voren komen:

• Horizontaal filteren — ongeveer dertig operators (eq, gt, like, ilike, in, is, cs, ov, fts...) rechtstreeks in de queryreeks.
• Verticaal filteren en insluiten — ?select= projecteert kolommen en sluit relaties in via een externe sleutel, bijvoorbeeld customer:customers(email).
• RPC — een POST /rpc/{fonction} roept rechtstreeks een SQL-functie aan, die een eindpunt wordt.
• RLS aangestuurd door JWT — PostgREST schakelt de actieve Postgres-rol volgens het ontvangen token (SET LOCAL ROLE), zodat uw beleid van toepassing is zoals het is, zonder dubbele autorisatielogica aan de applicatiezijde.
• Zelf gegenereerde OpenAPI — de specificatie is afgeleid van het blootgestelde schema, zonder een bestand dat handmatig moet worden onderhouden.

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

Eén enkel HTTP-verzoek filtert betaalde bestellingen, sluit de e-mail van de klant in via een externe sleutel en sorteert op datum – zonder dat er ook maar één route met de hand hoeft te worden geschreven.

De RPC volgt dezelfde logica: een SQL-functie die al in uw database is geschreven, wordt een POST-eindpunt, waarvan de argumenten worden doorgegeven in JSON.

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

Dit principe – het Postgres-schema is de enige bron van waarheid van de API – maakt PostgREST voorspelbaar: elke gedragsverandering gaat via een SQL-migratie, nooit via een aparte applicatielaag die zou kunnen voortkomen uit het daadwerkelijke schema. Het project is open source, ontwikkeld op GitHub, onafhankelijk van een bepaalde BaaS-provider.

PostgREST lost de CRUD-laag op. Het lost de rest van de backend van een applicatie niet op. Er komen systematisch vier tekortkomingen voor bij teams die het alleen toepassen.

• Authenticatie — geen JWT-uitgifte of geïntegreerd gebruikersbeheer. U moet het in SQL bouwen of delegeren aan een externe service.
• Bestandsopslag — geen. Een S3-bucket of gelijkwaardig moet nog apart worden aangesloten.
• Realtime — PostgREST reageert op eenmalige HTTP-verzoeken, het pusht geen gebeurtenissen.
• Verbindingspooler — PostgREST maakt zelf verbinding met Postgres, maar integreert geen geavanceerde poolers. Op grote schaal wordt het beheer ervan een operationele beslissing op zich: een pooler in de klassieke transactiemodus conflicteert met het PostgREST-schemaherlaadmechanisme (zie hieronder hoe Aurabase dit compromis oplost).

Een praktisch gevolg verdient het om duidelijk vermeld te worden: zonder authenticatie wordt uw RLS-beleid de enige beveiligingsgrens tussen een anonieme klant en uw gegevens. Een slecht geschreven beleid voor de rol anon wordt niet ingehaald door een extra applicatielaag; die is er niet.

Op een Aurabase Postgres-engineproject (de standaardengine) routeert de gateway elk CRUD-verzoek rechtstreeks naar een PostgREST v12.2.8-instantie die aan dit project is gewijd, twee replica's, die zich op dezelfde locatie bevinden als het Postgres-cluster van de huurder. Dit is geen geschatte compatibiliteit: het is het postgREST upstream binaire bestand zelf, met dezelfde operators, dezelfde inbedding, dezelfde RPC, dezelfde RLS aangedreven door JWT.

Bij een MongoDB-engineproject is het verhaal anders. MongoDB heeft geen equivalent van PostgREST: deze verzoeken worden doorgestuurd naar een interne Aurabase-service, die een subset van dezelfde conventies opnieuw implementeert – identieke operatornamen, ?select= syntaxis met inbedding, Prefer en Content-Range headers – maar op een documentengine, niet op een relationele engine. Deze laag heeft zijn eigen beperkingen: een inbedding gevraagd in de representatie die door een mutatie wordt geretourneerd, wordt expliciet geweigerd in plaats van stilzwijgend genegeerd, en er is geen RPC-route die gelijkwaardig is aan SQL-functies.

Een technisch detail staat in contrast met de intuïtie: elke specifieke PostgREST-instantie blijft rechtstreeks verbonden met de primaire Postgres, zonder de PgBouncer-pooler te doorlopen die voor deze tenant is ingezet. Vermoedelijke reden: de modus voor transactiepooling zou het herladen van het PostgREST-schema verbreken, dat afhankelijk is van LISTEN/NOTIFY: een persistente verbinding, incompatibel met een pool die de verbinding voor elke transactie recycleert.

Nog een nuttig detail in de productie: een inactief project kan worden gepauzeerd om middelen te besparen. Het eerste verzoek voor een slapend project activeert het ontwaken en ontvangt een 503 met een vertraging voor opnieuw proberen, de tijd die de speciale PostgREST-instantie nodig heeft om weer actief te worden - een verondersteld compromis tussen kosten en koude latentie, en niet een verborgen incident.

PostgREST heeft een duidelijk nut: het Postgres-schema is de bron van de waarheid en het team wil voorkomen dat er met de hand een CRUD-laag wordt geschreven. Afgezien van dit specifieke geval bestaan ​​er verschillende families van alternatieven, afhankelijk van wat je eraan wilt toevoegen – van helemaal niets (zelf gehost) tot een complete kant-en-klare backend.

In de onderstaande tabel wordt vergeleken wat elke optie standaard omvat en wat expliciet aan u wordt overgelaten - zonder waardeoordeel over de door elk project gekozen architectuur.

Een punt dat vaak wordt onderschat bij het kiezen voor "self-hosted": PostgREST zelf blijft licht om te draaien, maar de productieoperatie (versie-update, hoge beschikbaarheid, associatie met een pooler, monitoring) blijft volledig jouw verantwoordelijkheid - het is dit operatiewerk, niet de software, dat beheerde platforms absorberen.

Voor een gedetailleerde vergelijking tussen GraphQL-benaderingen — pg_graphql, Hasura en PostGraphile — zie ons artikel gewijd aan de GraphQL API op Postgres.

Vier situaties komen het vaakst voor. De juiste keuze hangt vooral af van wat u zelf wilt monteren en onderhouden.

• U wilt gewoon een REST API over een bestaand Postgres-schema, niets anders. Zelf-gehoste PostgREST is voldoende: het doet precies wat het doet en er hoeft niets anders te worden geïnstalleerd.
• Je hebt extra authenticatie, opslag en realtime nodig, en je bent klaar om verschillende services samen te stellen. Supabase, of PostgREST vergezeld van uw eigen applicatiestack, voldoet aan deze behoefte.
• U geeft de voorkeur aan GraphQL boven REST. Hasura of PostGraphile bestrijken dit terrein – een andere architectonische keuze, geen directe vervanging voor PostgREST.
• U wilt een complete Postgres-backend zonder meerdere afzonderlijke services aan elkaar te koppelen. Dit is de invalshoek waarmee onze Rust-architectuur documenteert: echte PostgREST voor de CRUD-laag, native omgeven door auth-, opslag-, realtime- en edge-functies.