PostgREST compatibility: what it covers, and alternatives

PostgREST is an autonomous web server that transforms an existing PostgreSQL database into a REST API, directly from its schema. No application layer to write: tables, views and functions become routes, and SQL permissions — roles, RLS policies — become the authorization layer.

Concretely, PostgREST covers five capabilities that come up in almost all evaluations:

• Horizontal filtering — around thirty operators (eq, gt, like, ilike, in, is, cs, ov, fts...) directly in query string.
• Vertical filtering and embedding — ?select= projects columns and embeds relationships via foreign key, for example customer:customers(email).
• RPC — an POST /rpc/{fonction} directly calls an SQL function, which becomes an endpoint.
• RLS driven by JWT — PostgREST switches the active Postgres role according to the token received (SET LOCAL ROLE), so your policies apply as is, without duplicate authorization logic on the application side.
• Self-generated OpenAPI — the specification is deduced from the exposed schema, without a file to maintain by hand.

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

A single HTTP request filters paid orders, embeds the customer's email via foreign key, and sorts by date — without a single route having to be written by hand.

The RPC follows the same logic: an SQL function already written in your database becomes a POST endpoint, with its arguments passed 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}'

This principle — the Postgres schema is the API's single source of truth — is what makes PostgREST predictable: every behavior change goes through an SQL migration, never through a separate application layer that could derive from the actual schema. The project is open source, developed on GitHub, independent of any particular BaaS provider.

PostgREST resolves the CRUD layer. It does not resolve the rest of an application backend. Four shortcomings systematically occur among teams that adopt it alone.

• Authentication — no JWT issuance or integrated user management. You must build it in SQL or delegate it to an external service.
• File storage — none. An S3 bucket or equivalent remains to be connected separately.
• Real time — PostgREST responds to one-off HTTP requests, it does not push any events.
• Connection Pooler — PostgREST itself connects to Postgres, but does not integrate any advanced poolers. At scale, managing it becomes an operating decision in its own right: a pooler in classic transaction mode conflicts with the PostgREST schema reloading mechanism (see below how Aurabase resolves this compromise).

A practical consequence deserves to be stated clearly: without authentication, your RLS policies become the only security boundary between an anonymous customer and your data. A poorly written policy on the anon role is not overtaken by an additional application layer — there is none.

On an Aurabase Postgres engine project — the default engine — the gateway routes each CRUD request directly to a PostgREST v12.2.8 instance dedicated to this project, two replicas, co-located with the tenant's Postgres cluster. This is not approximate compatibility: it is the PostgREST upstream binary itself, with the same operators, the same embedding, the same RPC, the same RLS driven by JWT.

On a MongoDB engine project, the story is different. MongoDB has no equivalent to PostgREST: these requests are routed to an internal Aurabase service, which reimplements a subset of the same conventions — identical operator names, ?select= syntax with embedding, Prefer and Content-Range headers — but on a document engine, not a relational one. This layer has its own limitations: an embedding requested in the representation returned by a mutation is explicitly denied rather than silently ignored, and there is no RPC route equivalent to SQL functions.

A technical detail contrasts with intuition: each dedicated PostgREST instance remains directly connected to the primary Postgres, without going through the PgBouncer pooler deployed for this tenant. Assumed reason: transaction pooling mode would break PostgREST schema reloading, which relies on LISTEN/NOTIFY — a persistent connection, incompatible with a pool that recycles the connection for each transaction.

Another useful detail in production: an inactive project can be paused to save resources. The first request on a sleeping project triggers its wake-up and receives an 503 with a retry delay, the time for the dedicated PostgREST instance to come back up — an assumed compromise between cost and cold latency, not a hidden incident.

PostgREST has a clear use: the Postgres schema is the source of truth, and the team wants to avoid writing a CRUD layer by hand. Apart from this specific case, several families of alternatives exist depending on what you want to add around — from nothing at all (bare self-hosted) to a complete ready-to-use backend.

The table below compares what each option covers natively and what it leaves explicitly up to you — without value judgment on the architecture chosen by each project.

A point often underestimated when choosing "self-hosted": PostgREST itself remains light to run, but production operation (version update, high availability, association with a pooler, monitoring) remains entirely your responsibility - it is this operation work, not the software, that managed platforms absorb.

For a detailed comparison between GraphQL approaches — pg_graphql, Hasura and PostGraphile — see our article dedicated to the GraphQL API on Postgres.

Four situations come up most often. The right choice depends mainly on what you are willing to assemble and maintain yourself.

• You just want a REST API over an existing Postgres schema, nothing else. Self-hosted PostgREST is enough: it does exactly what it does, and nothing else needs to be installed.
• You need additional auth, storage and real-time, and you are ready to assemble several services. Supabase, or PostgREST accompanied by your own application stack, meets this need.
• You prefer GraphQL to REST. Hasura or PostGraphile cover this ground — a different architectural choice, not a direct replacement for PostgREST.
• You want a complete Postgres backend without stitching together multiple separate services. This is the angle that our unified Rust architecture documents: real PostgREST for the CRUD layer, natively surrounded by auth, storage, real-time and edge functions.