PostgREST : que couvre vraiment la compatibilité, et quelles alternatives existent

PostgREST est un serveur web autonome qui transforme une base PostgreSQL existante en API REST, directement depuis son schéma. Aucune couche applicative à écrire : les tables, les vues et les fonctions deviennent des routes, et les permissions SQL — rôles, policies RLS — deviennent la couche d’autorisation.

Concrètement, PostgREST couvre cinq capacités qui reviennent dans la quasi-totalité des évaluations :

• Filtrage horizontal — une trentaine d’opérateurs (eq, gt, like, ilike, in, is, cs, ov, fts...) directement en query string.
• Filtrage vertical et embedding — ?select= projette des colonnes et embarque des relations via clé étrangère, par exemple customer:customers(email).
• RPC — un POST /rpc/{fonction} appelle directement une fonction SQL, qui devient un endpoint.
• RLS pilotée par JWT — PostgREST bascule le rôle Postgres actif selon le token reçu (SET LOCAL ROLE), donc vos policies s’appliquent telles quelles, sans logique d’autorisation dupliquée côté application.
• OpenAPI auto-généré — la spécification se déduit du schéma exposé, sans fichier à maintenir à la main.

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

Une seule requête HTTP filtre les commandes payées, embarque l’email du client via la clé étrangère, et trie par date — sans qu’une seule route n’ait été écrite à la main.

Le RPC suit la même logique : une fonction SQL déjà écrite dans votre base devient un endpoint POST, avec ses arguments passés en 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}'

Ce principe — le schéma Postgres est la seule source de vérité de l’API — est ce qui rend PostgREST prévisible : chaque changement de comportement passe par une migration SQL, jamais par une couche applicative séparée qui pourrait dériver du schéma réel. Le projet est open source, développé sur GitHub, indépendant de tout fournisseur BaaS particulier.

PostgREST résout la couche CRUD. Il ne résout pas le reste d’un backend applicatif. Quatre manques reviennent systématiquement chez les équipes qui l’adoptent seul.

• Authentification — pas d’émission de JWT ni de gestion d’utilisateurs intégrée. Il faut la construire en SQL ou la déléguer à un service externe.
• Stockage de fichiers — aucun. Un bucket S3 ou équivalent reste à brancher séparément.
• Temps réel — PostgREST répond à des requêtes HTTP ponctuelles, il ne pousse aucun événement.
• Pooler de connexions — PostgREST se connecte lui-même à Postgres, mais n’intègre aucun pooler avancé. À l’échelle, le gérer devient une décision d’exploitation à part entière : un pooler en mode transaction classique entre en conflit avec le mécanisme de rechargement de schéma de PostgREST (voir plus bas comment Aurabase tranche ce compromis).

Une conséquence pratique mérite d’être dite clairement : sans authentification devant, vos policies RLS deviennent la seule frontière de sécurité entre un client anonyme et vos données. Une policy mal écrite sur le rôle anon n’est pas rattrapée par une couche applicative supplémentaire — il n’y en a pas.

Sur un projet Aurabase moteur Postgres — le moteur par défaut — le gateway route chaque requête CRUD en direct vers une instance PostgREST v12.2.8 dédiée à ce projet, deux réplicas, colocalisée avec le cluster Postgres du tenant. Ce n’est pas une compatibilité approchée : c’est le binaire PostgREST upstream lui-même, avec les mêmes opérateurs, le même embedding, le même RPC, la même RLS pilotée par JWT.

Sur un projet moteur MongoDB, l’histoire est différente. MongoDB n’a pas d’équivalent à PostgREST : ces requêtes sont routées vers un service Aurabase interne, qui réimplémente un sous-ensemble des mêmes conventions — noms d’opérateurs identiques, syntaxe ?select= avec embedding, en-têtes Prefer et Content-Range — mais sur un moteur documentaire, pas relationnel. Cette couche a ses propres limites : un embedding demandé dans la représentation renvoyée par une mutation est explicitement refusé plutôt que silencieusement ignoré, et il n’existe pas de route RPC équivalente aux fonctions SQL.

Un détail technique tranche avec l’intuition : chaque instance PostgREST dédiée reste connectée en direct au primaire Postgres, sans passer par le pooler PgBouncer déployé pour ce tenant. Raison assumée : le mode transaction pooling casserait le rechargement de schéma de PostgREST, qui repose sur LISTEN/NOTIFY — une connexion persistante, incompatible avec un pool qui recycle la connexion à chaque transaction.

Autre détail utile en production : un projet inactif peut être mis en pause pour économiser des ressources. La première requête sur un projet endormi déclenche son réveil et reçoit un 503 avec un délai de nouvelle tentative, le temps que l’instance PostgREST dédiée remonte — un compromis assumé entre coût et latence à froid, pas un incident caché.

PostgREST a un usage clair : le schéma Postgres est la source de vérité, et l’équipe veut éviter d’écrire une couche CRUD à la main. En dehors de ce cas précis, plusieurs familles d’alternatives existent selon ce que vous voulez ajouter autour — de rien du tout (auto-hébergé nu) à un backend complet prêt à l’emploi.

Le tableau ci-dessous compare ce que chaque option couvre nativement et ce qu’elle laisse explicitement à votre charge — sans jugement de valeur sur l’architecture choisie par chaque projet.

Un point souvent sous-estimé au moment de choisir « auto-hébergé » : PostgREST lui-même reste léger à faire tourner, mais l’exploitation en production (mise à jour de version, haute disponibilité, association à un pooler, surveillance) reste entièrement à votre charge — c’est ce travail d’exploitation, pas le logiciel, que les plateformes managées absorbent.

Pour un comparatif détaillé entre les approches GraphQL — pg_graphql, Hasura et PostGraphile — voir notre article dédié à l’API GraphQL sur Postgres.

Quatre situations reviennent le plus souvent. Le bon choix dépend surtout de ce que vous êtes prêt à assembler et maintenir vous-même.

• Vous voulez juste une API REST sur un schéma Postgres existant, sans rien d’autre. PostgREST auto-hébergé suffit : c’est exactement le métier qu’il fait, et rien d’autre à installer.
• Vous avez besoin d’auth, de storage et de temps réel en plus, et vous êtes prêt à assembler plusieurs services. Supabase, ou PostgREST accompagné de votre propre stack applicative, répondent à ce besoin.
• Vous préférez GraphQL à REST. Hasura ou PostGraphile couvrent ce terrain — un choix d’architecture différent, pas un remplacement direct de PostgREST.
• Vous voulez un backend Postgres complet sans assembler plusieurs services distincts. C’est l’angle que documente notre architecture Rust unifiée : PostgREST réel pour la couche CRUD, entouré nativement d’auth, de storage, de temps réel et de fonctions edge.