What is the difference between Postgres and PostgREST?
People mash the names together because they share a root. They are not the same thing. Postgres is the database. PostgREST is a server that reads your Postgres schema and exposes it over HTTP. If you confuse the two on a vendor call, you will buy the wrong layer and wonder why nothing feels finished.
Postgres in one breath
PostgreSQL (Postgres for short) 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.
PostgREST in one breath
PostgREST is a standalone web server. You point it at a Postgres database. It looks at 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 difference that matters to a founder
| 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.
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.
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. DreamFactory style writeups on PostgREST are honest about this: 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 a public SQL hole with JSON on top.
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.
A simple decision rule
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?.
Work with Kleto
I am James Cowan, a product engineer and the founder of Kleto. Kleto is a product engineering agency that 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 and we will scope a sensible first step.