What is the difference between Postgres and PostgREST?
People mash the names together because they share a root. They are not the same thing, and confusing them on a vendor call is how you buy the wrong layer and wonder why nothing feels finished.
My take: Postgres is non negotiable for serious product data. PostgREST is optional. Add it when your API is mostly honest CRUD under database enforced rules. Skip it when your domain logic is the product and the database is storage behind a deliberate service boundary.
Postgres in one breath
PostgreSQL is where rows live. Tables, indexes, constraints, transactions, backups. It is the long memory of the product. When money moves, when a user owns a record, when a report must match last Tuesday, you want Postgres doing that work.
Postgres does not speak HTTP to browsers by itself. Your app, or some API layer, has to sit in front of it. That gap is where founders lose money on quotes that say "Postgres API" and mean three different things.
PostgREST in one breath
PostgREST is a standalone web server. Point it at Postgres. It reads schemas, tables, views, and functions, then serves a REST API shaped by that structure. Permissions in the database become permissions on the API. You spend less time writing the same create and update handlers by hand.
The PostgREST docs put it plainly: the database is the source of truth for the API shape. That is the whole pitch. The incentives favor vendors who sell you speed by exposing tables. The incentive on your side is to know whether your product actually wants that exposure.
The difference that matters when you sign a check
| Layer | Job | If it fails |
|---|---|---|
| Postgres | Store and protect data | You lose correctness, history, or uptime |
| PostgREST | Expose data over HTTP from the schema | Clients cannot talk to the database cleanly |
You can run Postgres for years without PostgREST. Plenty of products use Rails, Node, or Go as the API. You cannot run PostgREST without Postgres. One is the vault. The other is a door with rules.
Modern software is bloated partly because the industry sells cloud credits and headcount, not fast honest boundaries. PostgREST is the opposite bet: lean on what Postgres already knows instead of re encoding foreign keys in yet another ORM layer.
Why teams reach for PostgREST
Hand written CRUD often reimplements what the database already knows. Foreign keys, check constraints, row filters. PostgREST leans on that instead of hiding it behind an ORM that fights the schema.
For internal tools and early products, that speed is real. Define tables and views. Set roles. Ship a usable API. Pair it with a thin front end and you have a working system without a custom backend for every form.
I have seen founders ship a credible admin console in a week this way. I have also seen founders expose every table to the anon role and call it an MVP. Speed without policy review is not architecture. It is a public SQL hole with JSON on top.
What PostgREST does not buy you
It is not a full application platform. Complex workflows, multi step payments, weird third party glue, and heavy business rules still need code somewhere. Great at schema driven REST. Thin if you expected a complete backend product.
Row level security and careful roles are not optional. If every table is wide open to the anon role, you did not get an API. You got liability dressed as progress.
How this shows up in quotes and stacks
Vendors say "Postgres API" and mean three different things:
- Raw Postgres only (you build the API).
- PostgREST or a PostgREST flavored layer (schema is the API).
- A batteries included host like Supabase that uses PostgREST under the hood plus auth and storage.
Ask which one. Ask where authorization is enforced. Ask who owns migrations when the API shape changes. If the answers wander, you are not buying clarity. You are buying a demo that worked on someone's laptop.
A decision rule I would actually use
Use Postgres because you need durable product data. That decision stands alone.
Add PostgREST when your API is mostly "read and write these tables under these rules" and you want the schema to stay honest. Skip it when your domain logic is the product and the database is just storage behind a deliberate service boundary.
If you are still deciding whether a schema driven API is enough, read When is REST from the database enough?.
Lessons:
- Postgres is the vault. PostgREST is one kind of door. Do not conflate them on a quote line item.
- PostgREST wins when tables, views, and RLS can express your rules. It loses when orchestration and stable public contracts are the product.
- Speed from schema driven APIs is real. So are data leaks from skipped policy review. Budget time for both.
- Ask vendors to name the layer. "Postgres API" is marketing until someone points at the server.
Work with Kleto
I am James Cowan, a product engineer and the founder of Kleto. Kleto ships production software from strategy through handoff. We help teams pick the right boundary between the database and the API before that choice becomes expensive. If that matches your stack, contact Kleto.