PostgREST Promises to Delete Backend Code. Should You?

The pitch sounds too good: turn your Postgres database into a production-ready REST API without writing a single line of backend code. No controllers, no ORM layer, no middleware. Just your schema and some SQL.

Better Stack's recent demonstration of PostgREST delivers on that promise—at least technically. In their video, they go from an empty Docker container to a functioning API with filtering, sorting, pagination, and auto-generated documentation in under sixty seconds. The demo is clean. The concept is elegant. The question worth asking is whether this elegance scales beyond the demo.

The Translation Tax

Every backend developer knows the drill. You define your data model in the database. Then you define it again in your ORM. Then you write controllers that translate between the two. Then you add validation that duplicates the database constraints. Then you scatter authentication logic across middleware files. Same information, five different places, each a potential point of failure.

"Traditional backend work has a tax and most of that tax is not product work," the Better Stack presenter notes. "Really what we're doing is all this maintenance work, right?"

That rings true. I've watched this pattern repeat for decades under different names. The tooling changes—from Perl CGI to Rails to Node to whatever's next—but the fundamental duplication remains. PostgREST's core insight is simple: if your database already knows your schema, your relationships, and your constraints, why rebuild that knowledge elsewhere?

The tool exposes Postgres directly as a REST API. Your database schema becomes your API specification. Row-level security policies in SQL replace authentication middleware. Database relationships define your API's navigational structure. According to their approach, you're not building a translation layer—you're exposing data correctly from the start.

The Demo Gap

The demonstration is compelling precisely because it's simple. A basic to-do table with four columns. Row-level security set to allow everything temporarily. A few curl commands to test CRUD operations. Swagger documentation that appears automatically.

What the demo doesn't show is what happens when requirements get messy. Real applications rarely deal with single tables and simple access patterns. They have complex business logic that doesn't map cleanly to SQL functions. They need to call external services. They aggregate data from multiple sources. They cache aggressively. They handle file uploads, send emails, process payments.

PostgREST's answer to this complexity is: write SQL functions and views. For some developers, this is liberating—they prefer SQL to JavaScript or Python for data operations. For others, it's a regression to stored procedure architectures from the 1990s, complete with the same debugging and testing challenges.

The video acknowledges this tension: "Complex logic can push you towards lots of SQL functions or views and some people love that and some people are going to hate that."

That's a carefully neutral statement that papers over a genuine philosophical divide in software architecture. Moving logic into the database has implications for testing, versioning, deployment, and team structure. These aren't minor concerns.

The Security Proposition

Row-level security is PostgREST's most interesting feature and its most significant risk. The idea is sound: define access control where the data lives, using the database's native policy system. This eliminates the gap between what your middleware thinks is allowed and what your database will actually permit.

"Security lives in the database," the presenter explains. "It's not scattered across middleware or root handlers."

But Postgres's row-level security was designed for database users, not for application-level authorization patterns. Making it serve both purposes requires careful design. The demo shows a permissive policy that allows everything—fine for a prototype, problematic for anything facing the internet.

The video notes that "heavy row-level security usage is going to increase the database load." This understates the problem. Every query now carries authorization overhead. For simple cases, the performance hit is negligible. For complex policies across large datasets, it can be significant. You're trading application server CPU for database CPU, and databases are usually the bottleneck you're trying to protect.

The Supabase Factor

PostgREST's legitimacy credential is Supabase, the Firebase alternative that's processed serious venture capital and powers production applications. Supabase uses PostgREST as its core API layer, which proves the concept can handle real traffic.

But Supabase also wraps PostgREST in additional services—authentication, storage, real-time subscriptions, edge functions. They've built the very abstraction layer that PostgREST is supposed to eliminate. That's not a criticism of either tool. It's recognition that production systems need more than clean database access.

Where This Fits

The demo suggests PostgREST for "prototypes, MVPs, or anything centered around Postgres." That's probably right, with emphasis on "centered around Postgres." If your application is fundamentally about creating, reading, updating, and querying structured data—if that's 90% of what you do—then PostgREST eliminates genuine tedium.

For applications where the database is one component among many, where business logic lives in code for good reasons, where you need fine-grained control over performance and caching, the value proposition weakens. The video acknowledges this: "If your app has really complex logic, you may still want a thin backend layer on top."

Once you're writing a backend layer anyway, you're back to making the same architectural decisions PostgREST was supposed to eliminate. The database-as-API works best when you commit to it fully, which means accepting its constraints.

The Pattern Returns

I've seen this cycle before. In the late 1990s, stored procedures were going to eliminate application servers. In the mid-2000s, REST was going to eliminate custom APIs. A decade ago, GraphQL was going to eliminate REST. Each time, the new approach solved real problems while creating new ones. The surviving tools found their niche rather than replacing everything that came before.

PostgREST will likely follow the same arc. It's a genuine contribution—26,000 GitHub stars suggest people find it useful. For certain projects, it's probably the right choice. The question is whether your project is one of them, and the demo makes that look easier to answer than it actually is.

Bob Reynolds is Senior Technology Correspondent for Buzzrag.