PostgREST Deletes 80% of Your Backend Code

BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00What if your Postgres database was the API and you didn't have to write any backend code at all?
00:00:05Every time you build an API you write the same backend code over and over. Roots, controllers, validation, auth, all this just to talk to your
00:00:14database. Then you change one column and everything breaks. No custom backend code. No controllers. No ORM layer.
00:00:21That's what Postgres does. It's the engine behind Supabase. It handles serious production traffic and in just a few minutes
00:00:29I'm going to show you how.
00:00:31Now if you build APIs this one hits the most annoying pain points in the whole stack.
00:00:40Duplicated logic. You define the data in the database.
00:00:44Then you define access rules and backend code and validation somewhere else.
00:00:49Then we do the same for response handling somewhere else. Same system, multiple layers, multiple chances for things to break.
00:00:56Postgres cuts through all this. It has over 26,000 stars on GitHub and it's used by Supabase at production scale.
00:01:03It turns your schema into a production ready REST API in just minutes. There's no ORM, no controllers.
00:01:10Security lives in the database, which means less duplication, less maintenance, and way more less time spent wiring all that boring stuff together.
00:01:19Let me show you. If you enjoy coding tools that speed up your workflow, be sure to subscribe.
00:01:24We have videos coming out all the time.
00:01:26All right. Now let's actually build this thing. Okay, here is the setup. Three containers.
00:01:32That's it. Postgres, Postgrest, and Swagger UI for some docs.
00:01:38Here's the Docker Compose file. There's nothing much going on here. Just three services that I've wired together.
00:01:45I spin it up with our surefire command Docker Compose. It's gonna get running and I'm done.
00:01:51There's no installing dependencies. No setting up a server. Now, let's look at the database.
00:01:55I'm gonna run the stalker command here and that's it. A super simple todos table. ID, title, completed, created, all the basic stuff.
00:02:04That's really, that's all that's going on here. But this, this is the part where it becomes useful.
00:02:09Row level security. We define who can access what directly in SQL inside the database.
00:02:17No backend auth logic sitting somewhere else in our system. Here's the policy.
00:02:22I have anon full access using true with check true. So for now, everything is allowed. Now watch this.
00:02:29I'm going to hit get todos with this curl command and that's it. Full JSON straight from Postgres.
00:02:35No API code. Now building on that, let me filter it out now. It works immediately.
00:02:41If I sort it, boom, there we go. Now let's create another row, send a post request with a JSON body and we're done.
00:02:50And it's already in the database. There's no ORM layer trying to catch up here.
00:02:56And here's the part that really gets people with this. Open API docs, auto-generated Swagger UI. It's just here.
00:03:04I open it and we get a full interactive API. You can explore everything, test endpoints, see schemas.
00:03:11So from zero, you now have full CRUD, filtering, sorting, pagination. You have basic auth via RLS and docs in just under a minute.
00:03:21So why do people even use this? Well, if that wasn't enough, because traditional backend work has attacks.
00:03:26And most of that tax is not product work. Really what we're doing is all this maintenance work, right?
00:03:33If you think about the normal stack, maybe it's express, Prisma, controllers, services, validation in one place.
00:03:40Then we have auth in another place. Your database logic is somewhere else entirely.
00:03:45Now compare that to postgres. Your schema defines the API. Your security is RLS.
00:03:52Your relationships already exist in the database. So instead of building a translation layer around your data, we just expose the data correctly.
00:04:02That's very different. Now compare that to a custom backend. You have to write everything yourself.
00:04:07That gives you flexibility. Yeah, sure. But it also gives you a lot more code to maintain.
00:04:13Postgres stays simpler. REST plus postgres. Security is in the database. It's not scattered across middleware or root handlers.
00:04:23Your maintenance stays low because your API tracks your schema. That's why people like it.
00:04:28Now, to be fair, this is where people get in trouble because once something starts to feel clean like this, people start acting like it solves everything.
00:04:34This doesn't solve everything, right? There's still things we have to look out for.
00:04:38There's going to be trade-offs and you should know what to watch out for before you even touch this.
00:04:43What people love here is, well, kind of obvious. It's fast to build with. You can go from idea to working API really fast.
00:04:51And it does scale really well, too. On top of that, right, Superbase kind of proves it.
00:04:55They're using this. But the downsides here are things like heavy row level security usage is going to increase the database load.
00:05:02So you need to think carefully about how you design this. Complex logic can push you towards lots of SQL functions or views.
00:05:10And some people love that and some people are going to hate that. So should you use this or even try it?
00:05:15Yeah, for the right projects. If you're building prototypes, MVPs or anything centered around Postgres, then sure, why not give it a try, right?
00:05:23You're going to move faster. You're going to write less code and you get stronger security defaults by pushing the rules down into the database.
00:05:32Now, if your app has really complex logic, you may still want a thin backend layer on top, something small, a BFF layer for edge cases.
00:05:40But even then, Postgres can do most of the heavy lifting underneath. So the big takeaway is this. Postgres lets you ship faster, secure better and maintain less.
00:05:50Your database becomes the source of actual data, and your API falls out of that instead of becoming its own separate system.
00:05:58If you enjoy coding tools and tips like this, be sure to subscribe to the Better Stack channel. We'll see you in another video.

Key Takeaway

PostgREST eliminates 80% of backend development by exposing a Postgres database directly as a REST API and moving security logic into Row Level Security.

Highlights

PostgREST transforms a Postgres schema into a production-ready REST API in minutes without any custom backend code, controllers, or ORM layers.

The tool reduces backend code by up to 80% by consolidating data definitions, access rules, and validation logic directly within the database.

Row Level Security (RLS) handles authentication and authorization at the database level, preventing security rules from being scattered across middleware.

PostgREST automatically generates Open API documentation and a Swagger UI for interactive API exploration and testing.

Supabase utilizes PostgREST to manage production-scale traffic, demonstrating the tool's capability for high-load environments.

Complex logic is managed through SQL functions and views, though heavy RLS usage increases database CPU load.

Timeline

The Backend Redundancy Problem

  • Traditional API development involves repeating routes, controllers, validation, and auth logic for every database interaction.
  • Schema changes frequently break multiple layers of the stack because logic is duplicated across the database and the backend code.
  • A single source of truth in the database reduces the chances for systemic failure.

Building APIs typically requires a translation layer between the database and the client. This stack often includes an ORM, controllers, and services that must be manually updated whenever a column changes. Moving these responsibilities to the database itself removes the friction of maintaining parallel logic systems.

Core Features and Production Performance

  • PostgREST has earned over 26,000 stars on GitHub as a widely adopted open-source tool.
  • Supabase relies on this engine to serve production traffic at scale.
  • The system replaces the ORM and controller layers with direct schema-to-API mapping.

High adoption rates and its role in the Supabase ecosystem prove the tool's reliability for professional applications. By centering security and relationships in the database, developers spend less time on 'boring' wiring and more on product-specific features. This shift simplifies the maintenance lifecycle significantly.

Implementation and Database Configuration

  • The environment runs on three containers: Postgres, PostgREST, and Swagger UI.
  • A standard Docker Compose file initializes the full API without installing local server dependencies.
  • Row Level Security (RLS) policies define access permissions using standard SQL 'CHECK' and 'USING' clauses.
  • Standard HTTP methods like GET, POST, and PATCH work immediately for filtering, sorting, and pagination.

Setting up the API involves spinning up a Docker container rather than writing server code. A basic 'todos' table with ID, title, and status columns becomes instantly queryable via curl. Security is enforced by the database engine itself, ensuring that even direct database connections follow the same permission rules as the API.

Architectural Comparison and Trade-offs

  • Traditional stacks like Express and Prisma require manual maintenance of translation layers.
  • PostgREST APIs track the schema automatically, keeping maintenance costs low.
  • Flexibility is the main advantage of custom backends, but it comes at the cost of increased code volume.

The 'backend tax' refers to the non-product maintenance work required to keep an API in sync with its data source. PostgREST avoids this by making the API a reflection of the schema. While this approach is cleaner, it requires developers to be comfortable with database-centric architecture rather than traditional middleware patterns.

Use Cases and Constraints

  • Intensive RLS usage increases database load and requires careful design to avoid performance bottlenecks.
  • Highly complex logic may require a thin 'Backend for Frontend' (BFF) layer for specific edge cases.
  • Prototypes and MVPs benefit most from the speed and security defaults provided by this approach.

PostgREST is ideal for Postgres-centric projects where rapid shipping is a priority. For apps with extreme logic requirements, it can still handle the bulk of data operations while a small secondary layer manages complex external integrations. The final result is a system where the API is a natural byproduct of the data structure.

Community Posts

View all posts