Development

PostgREST: Why Write Backend Code When Your Database Can Be the API?

Hazem Abbas

09 Apr 2026 — 7 min read

If you have ever spent a weekend building yet another Express.js or Django backend just to expose CRUD endpoints, you know the feeling. You write the models, the controllers, the serializers, the auth middleware, the OpenAPI docs, the tests for the tests. And for what? To move JSON from a database to a client.

What if you could skip 90% of that boilerplate and let your PostgreSQL database do the heavy lifting?

Enter PostgREST: the open-source tool that turns your PostgreSQL schema into a fully RESTful API instantly. No backend code. No ORM layer. No controller fatigue. Just your data, exposed securely, performantly, and automatically.

In this post, we will break down why PostgREST is changing how developers think about backend architecture, who should use it, and how to get started without rewriting your entire stack.

What Is PostgREST and Why Should You Care?

PostgREST is a standalone web server written in Haskell that connects directly to your PostgreSQL database. It reads your schema, tables, views, functions, relationships, and automatically generates a RESTful API that follows best practices out of the box.

Think of it as a universal adapter for your data layer. Instead of writing:

// Traditional backend: 50 lines for one endpoint
app.get('/users/:id', async (req, res) => {
  const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
  if (!user) return res.status(404).json({ error: 'Not found' });
  // auth check, serialization, error handling...
  res.json(user);
});

You get this automatically:

GET /users?id=eq.123

And PostgreSQL does the rest. Filters, relationships, pagination, sorting, all via query parameters. No custom code required.

How Does PostgREST Actually Work Under the Hood?

PostgREST is not a magic black box. It is a carefully engineered layer that leverages PostgreSQL's most powerful features:

Schema introspection: It reads your tables, views, foreign keys, and comments to build the API contract.
Direct SQL execution: Queries are constructed and executed natively in PostgreSQL, with JSON serialization happening in the database.
Role-based security: Every request runs as a specific database role. Authorization is controlled via PostgreSQL's GRANT/REVOKE system.
JWT authentication: Users authenticate via JSON Web Tokens, which PostgREST maps to database roles.

The result? Subsecond response times at 2,000+ requests per second, even on modest hardware.

And because it is written in Haskell with the Warp HTTP server and Hasql for connection pooling, it is stable, type-safe, and production-ready.

Why Would You Use PostgREST Instead of a Traditional Backend Framework?

Great question. PostgREST is not a silver bullet, but it shines in specific scenarios:

You Are Building a Greenfield Project with a Strong Data Model

If your application is data-centric and your schema is well-designed, PostgREST lets you ship an API in hours, not weeks. You focus on the frontend and business logic, not boilerplate endpoints.

You Need a Fast, Read-Heavy API

PostgREST excels at read operations. Complex joins, aggregations, and filters are pushed down to PostgreSQL, which is optimized for exactly this kind of workload.

You Want to Enforce Data Integrity at the Source

With PostgREST, your database is the single source of truth. Constraints, foreign keys, and check constraints live in PostgreSQL, not scattered across application code. No backend can accidentally bypass your rules.

You Are Tired of Maintaining OpenAPI Docs

PostgREST generates OpenAPI specifications automatically from your schema. Hook up Swagger-UI, and you have interactive, always-up-to-date documentation. No more syncing docs with code.

How Do You Handle Authentication and Authorization?

Security is built into PostgREST, not bolted on. Here is the flow:

A client sends a request with a JWT in the Authorization header.
PostgREST validates the token and extracts the user's role.
The request is executed in PostgreSQL under that role.
PostgreSQL's native permission system (GRANT/REVOKE) controls what the role can see or modify.

This means your authorization logic lives in one place: your database. No more syncing permissions between your auth service, your API layer, and your data layer.

Example:

-- In PostgreSQL
CREATE ROLE app_user;
GRANT SELECT ON users TO app_user;
GRANT UPDATE ON users TO app_user WITH GRANT OPTION;

-- In your JWT
{
  "role": "app_user",
  "user_id": 123
}

Now, any request with that JWT can only do what app_user is allowed to do. Simple, declarative, and auditable.

What About Complex Business Logic? Can PostgREST Handle It?

Yes—and this is where PostgreSQL's power really shines. PostgREST exposes not just tables, but also:

Views: Pre-computed joins or aggregations become first-class API resources.
Stored procedures: Call functions via POST /rpc/function_name.
Triggers and constraints: Enforce business rules at the database level.

Need to calculate a user's lifetime value, apply a discount, and log the transaction atomically? Write a PostgreSQL function, expose it via PostgREST, and call it like any other endpoint.

-- In PostgreSQL
CREATE FUNCTION apply_discount(user_id INT, code TEXT)
RETURNS TABLE(order_id INT, total NUMERIC) AS $$
BEGIN
  -- Complex logic here
  RETURN QUERY SELECT ...;
END;
$$ LANGUAGE plpgsql;

POST /rpc/apply_discount
{
  "user_id": 123,
  "code": "SUMMER2026"
}

No custom backend required. Your logic runs where your data lives.

How Do You Version an API Built with PostgREST?

Traditional API versioning often means maintaining multiple codebases or complex routing logic. PostgREST takes a cleaner approach: use PostgreSQL schemas.

Put v1 tables in a schema called api_v1.
When you need to change the contract, create api_v2 with new tables or views.
Point PostgREST to the appropriate schema via configuration or request headers.

Your frontend can request /v1/users or /v2/users, while your database stays organized and backward-compatible. No brittle endpoint deprecation cycles.

What About Performance? Is It Really Faster Than a Custom Backend?

In most read-heavy scenarios, yes. Here is why:

No ORM overhead: Queries go straight to PostgreSQL. No translation layer, no N+1 problems.
JSON in SQL: PostgreSQL can return JSON/JSONB directly, so PostgREST does not need to serialize in application code.
Connection pooling: Built-in via Hasql, so you avoid the cost of opening new connections per request.
Compiled, not interpreted: Haskell + Warp is fast. Benchmarks show 2,000+ req/sec on a free-tier VPS.

Of course, if you need heavy application-side computation or complex caching strategies, you might still want a custom service. But for most CRUD and reporting APIs, PostgREST is hard to beat.

How Do You Get Started with PostgREST?

Getting up and running takes minutes:

Or download a native binary for Linux, macOS, or Windows from the releases page.
Point your frontend or mobile app to http://localhost:3000 and start querying.

Configure via environment variables or a config file:

PGRST_DB_URI=postgres://user:pass@host:5432/db
PGRST_DB_SCHEMA=public
PGRST_DB_ANON_ROLE=anon
PGRST_JWT_SECRET=your-secret

Install via Docker (recommended):

docker run -p 3000:3000 postgrest/postgrest \
  postgrest postgres://user:pass@host:5432/db

That is it. No migrations for your API layer. No controller scaffolding. Just your data, exposed.

When Should You Not Use PostgREST?

PostgREST is powerful, but it is not for every use case. Consider a traditional backend if:

You need heavy application-side business logic that does not belong in the database.
You are integrating with multiple non-PostgreSQL data sources.
You require complex caching, rate limiting, or request transformation that is easier to implement in application code.
Your team is not comfortable managing authorization and logic at the database level.

In these cases, PostgREST can still be a great companion—use it for your core data API, and build custom microservices for the edge cases.

Ready to Let Your Database Be the Backend?

PostgREST represents a shift in how we think about backend development. Instead of writing code to move data, we design a robust, secure, well-structured schema—and let the database do what it does best.

If you are tired of boilerplate, if you trust PostgreSQL, and if you want to ship faster without sacrificing control, PostgREST is worth a look.

What do you think? Could your next project run on PostgREST? Have you tried it already? Drop your thoughts, questions, or war stories in the comments. Let us build the future of backend development—together.

Resources: