Skip to content
Written with Claude
IMPORTANT

As you may notice, this page and pretty much the entire website were obviously created with the help of AI. I wonder how you could tell? Was it a big "Written With Claude" badge on every page? I moved it to the top now (with the help of AI of course) to make it even more obvious. There are a few blogposts that were written by me manually, the old-fashioned way, I hope there will be more in the future, and those have a similar "Human Written" badge. This project (not the website), on the other hand, is a very, very different story. It took me more than two years of painstaking and unpaid work in my own free time. A story that, hopefully, I will tell someday. But meanwhile, what would you like me to do? To create a complex documentation website with a bunch of highly technical articles with the help of AI and fake it, to give you an illusion that I also did that manually? Like the half of itnernet is doing at this point? How does that makes any sense? Is that even fair to you? Or maybe to create this website manually, the old-fashioned way, just for you? While working a paid job for a salary, most of you wouldn't even get up in the morning. Would you like me to sing you a song while we're at it? For your personal entertainment? Seriously, get a grip. Do you find this information less valuable because of the way this website was created? I give my best to fix it to keep the information as accurate as possible, and I think it is very accurate at this point. If you find some mistakes, inaccurancies or problems, there is a comment section at the bottom of every page, which I also made with the help of the AI. And I woould very much appreciate if you leave your feedback there. Look, I'm just a guy who likes SQL, that's all. If you don't approve of how this website was constructed and the use of AI tools, I suggest closing this page and never wever coming back. And good riddance. And I would ban your access if I could know how. Thank you for your attention to this matter.

NpgsqlRest vs PostgREST vs Supabase: Complete Feature Comparison

Comparison · PostgREST · Supabase · January 2026


Choosing the right tool to expose your PostgreSQL database as a REST API can significantly impact your project's performance, maintainability, and development velocity. This comprehensive comparison examines three popular solutions: NpgsqlRest, PostgREST, and Supabase.

Executive Summary

AspectNpgsqlRestPostgRESTSupabase
What It IsComplete platform in a single binaryStandalone executable/DockerBackend-as-a-Service platform
Core FocusFunction-first REST API + full-stackTable/View-centric REST APIComplete backend platform
Best ForEnterprise features, self-hosted full-stackFlexible client-side queriesManaged hosting with dashboard
Performance4,588 req/s (100 VU)1,749 req/s (100 VU)Uses PostgREST internally
DeploymentSingle binary (~30MB), any cloudSingle binary (~20MB)Managed cloud or complex self-host
Self-HostingSimple (single binary)SimpleComplex (7+ services)
Learning CurveLow (SQL comments)Medium (RLS policies)Medium (platform concepts)

Architecture Comparison

NpgsqlRest

mermaid
flowchart LR
    A[Client] <--> B["NpgsqlRest
    (30MB AOT)
    Single executable"]
    B <--> C
    subgraph C [PostgreSQL]
        D["Comment Annotations
        (API config)"]
    end

NpgsqlRest is a complete platform in a single, self-contained executable that connects directly to PostgreSQL and serves REST APIs. API configuration lives in PostgreSQL as comment annotations on your functions and tables—custom paths, caching, rate limiting, authentication, and more, all version-controlled with your schema.

Beyond API generation, NpgsqlRest includes everything needed for full-stack development:

  • Static file serving with authorization and template parsing (replace placeholders with user claims)
  • TypeScript/JavaScript code generation for type-safe frontend clients
  • HTTP test file generation for API testing in VS Code and Visual Studio
  • Built-in authentication (JWT, encrypted Bearer, encrypted Cookie, Basic Auth, OAuth, Passkey/WebAuthn)
  • File uploads with image validation, CSV/Excel ingestion

No additional infrastructure required. Download, configure connection string, run. Deploy easily on any cloud server instance—AWS EC2, DigitalOcean, Hetzner, or your own servers.

PostgREST

mermaid
flowchart LR
    A[Client] <--> B["PostgREST
    (Haskell)
    Single executable"] <--> C[PostgreSQL]

PostgREST follows a similar single-binary model. Both are lightweight and straightforward to deploy.

Supabase

mermaid
flowchart LR
    A[Client] <--> B
    subgraph B [Supabase]
        direction TB
        subgraph row1 [" "]
            direction LR
            C[PostgREST]
            D[GoTrue]
            E[Realtime]
        end
        subgraph row2 [" "]
            direction LR
            F[Storage]
            G[Kong]
            H[Studio]
        end
        I[(PostgreSQL)]
    end

Supabase is a platform composed of multiple services. PostgREST handles REST API generation, GoTrue manages authentication, Kong provides API gateway functionality, and additional services handle storage, realtime, and the admin dashboard. Self-hosting requires orchestrating all these components.

Key difference: Both NpgsqlRest and Supabase are platforms, but NpgsqlRest packages everything into a single binary (~30MB) while Supabase requires 7+ separate services. Supabase offers a managed cloud service with a visual dashboard; NpgsqlRest gives you full control with simpler self-hosting on any cloud provider.

Performance Benchmarks

Benchmark results from PostgreSQL REST API Benchmark 2026, testing 14 frameworks under identical conditions:

Requests Per Second (100 Concurrent Users, 1 Record)

FrameworkRequests/secLatencyScaling Factor
NpgsqlRest JIT4,58810.88ms9.5x
NpgsqlRest AOT4,52711.02ms9.7x
Swoole PHP4,42311.29ms9.4x
Rust (Actix)3,94012.67ms7.8x
PostgREST1,74928.58ms6.5x

Key findings:

  • NpgsqlRest JIT is 2.6x faster than PostgREST at 100 concurrent users
  • PostgREST improved significantly in v14.3: from 271 req/s (1 user) to 1,749 req/s (100 users) - a 6.5x improvement
  • NpgsqlRest JIT scales excellently: from 480 req/s (1 user) to 4,588 req/s (100 users) - a 9.5x improvement
  • The gap between NpgsqlRest JIT and AOT has nearly closed (only 1.3% difference)

Larger Payloads (500 Records, 100 VU)

FrameworkRequests/secLatency
Swoole PHP106.88468ms
NpgsqlRest JIT82.37607ms
PostgREST78.59636ms

With larger payloads where database I/O dominates, the performance gap narrows significantly. Swoole PHP leads in data-heavy scenarios, while NpgsqlRest remains competitive with PostgREST.

PostgreSQL Type Handling

TypeNpgsqlRestPostgRESTSupabase
JSON/JSONB
Arrays (int[], text[])
Composite types
Date/Time types
Boolean
Variadic parameters
OUT parameters
Default parameters

All three frameworks handle PostgreSQL types correctly.

Feature Comparison Matrix

Platform Features

FeatureNpgsqlRestPostgRESTSupabase
Static file serving
Static file authorization
Template parsing (claim substitution)
TypeScript/JavaScript code generation
HTTP test file generation
Built-in authentication
File uploads
Visual dashboard
Managed cloud hosting
Single-binary deployment
Deploy on any cloud/server⚠️

⚠️ = Complex self-hosting (7+ services)

NpgsqlRest as a complete platform: Unlike PostgREST (API-only), NpgsqlRest includes everything needed to build and deploy full-stack applications:

  • Static file serving with path-based authorization—serve your frontend directly from NpgsqlRest
  • Template parsing replaces {claimType} placeholders in HTML files with authenticated user claims (name, email, role, etc.) before serving—build personalized pages without JavaScript
  • TypeScript/JavaScript code generation creates type-safe API clients automatically, keeping your frontend in sync with your database schema
  • HTTP test file generation creates .http files for VS Code REST Client and Visual Studio, enabling rapid API testing during development
  • Easy deployment on any cloud server (AWS EC2, DigitalOcean, Hetzner, Azure VM, GCP Compute) or on-premises—just copy the binary and run

Supabase offers different platform strengths: managed cloud hosting, a visual Studio dashboard for database management, and real-time WebSocket subscriptions. Choose Supabase if you prefer managed infrastructure and a visual interface; choose NpgsqlRest if you want full control with simpler self-hosting.

Core API Generation

FeatureNpgsqlRestPostgRESTSupabase
Functions as endpoints
Tables as endpoints
Views as endpoints
Function overloading
Custom URL paths
Path parameters (/users/{id})
OpenAPI/Swagger generation
TypeScript client generation
HTTP test file generation

Table and View Query Features

FeatureNpgsqlRestPostgRESTSupabase
Basic CRUD (SELECT/INSERT/UPDATE/DELETE)
INSERT RETURNING
ON CONFLICT (upsert)
Client-side filtering operators✅ (28+ operators)
Client-side resource embedding
Client-side aggregates
Client-side column selection
Client-side ordering/pagination

PostgREST and Supabase allow clients to compose queries against tables:

  • Resource embedding automatically joins related tables based on foreign keys
  • 28+ filtering operators including like, ilike, in, fts (full-text search), range operators
  • Aggregate functions with automatic GROUP BY

NpgsqlRest takes a function-first approach: these same capabilities (joins, full-text search, aggregates, filtering, pagination) are achieved through PostgreSQL functions. This is a deliberate design choice, not a limitation:

  • Full PostgreSQL power - Every query feature PostgreSQL offers is available: CTEs, window functions, recursive queries, full-text search, JSON operators, lateral joins—anything you can write in SQL
  • Optimized query plans - PostgreSQL optimizes your functions; client-composed queries may produce suboptimal plans
  • Security by design - You expose exactly what you intend to expose, not an entire table with filters
  • Predictable performance - No surprise queries that scan entire tables or create N+1 problems
  • Easier with modern AI tools - Writing PostgreSQL functions is straightforward, especially with AI assistance

Author's note: NpgsqlRest was designed with functions and stored procedures as the primary abstraction layer. Table/view endpoints exist for convenience, but I personally consider exposing raw tables directly to be a questionable engineering practice. Functions provide a proper API contract, encapsulate business logic, and give you full control over what data is exposed and how. — Vedran Bilopavlović, NpgsqlRest author

Choose PostgREST if you want clients to compose their own queries against tables. Choose NpgsqlRest if you prefer well-defined server-side endpoints with explicit query logic.

Custom Types and Nested JSON

FeatureNpgsqlRestPostgRESTSupabase
Return composite types as JSON
Return SETOF composite types
Nested composite types in response
Arrays of composite types (multiset)
Deep nesting (3+ levels)
Flat/merged composite mode
Composite type as parameter
Parameter field unnesting
TypeScript types for nested structures⚠️

✅ = Full support ⚠️ = Partial support or workarounds needed ❌ = Not supported

All three frameworks support PostgreSQL composite types and can return nested JSON structures, including arrays of composite types (multiset pattern). Key differences:

  • NpgsqlRest offers two modes: By default, composite type fields are merged/flattened into the parent object for simpler responses. Use the @nested annotation to preserve the hierarchical structure. PostgREST/Supabase always nest composite types.

  • Parameter unnesting: NpgsqlRest automatically expands composite type parameters into individual named fields (e.g., authorFirstName, authorLastName), making API consumption more intuitive. PostgREST/Supabase require passing composite parameters as nested JSON objects.

  • TypeScript generation: NpgsqlRest generates proper TypeScript interfaces for all nested structures automatically. Supabase generates types but may require manual casting for complex RPC return types. PostgREST has no built-in TypeScript generation (third-party tools like kanel can help).

  • Deep nesting: All three frameworks now handle arbitrary nesting depths. NpgsqlRest 3.4.4+ resolves nested composite types to any depth by default (configurable via ResolveNestedCompositeTypes). The only remaining limitation is 2D arrays of composite types at the return type level, which remain as tuple strings.

See Custom Types and Multiset for Nested JSON for detailed examples.

Authentication

FeatureNpgsqlRestPostgRESTSupabase
Token Schemes
Standard JWT Bearer token
Encrypted Bearer token (Microsoft Data Protection)
Encrypted Cookie
HTTP Basic authentication
Authentication Sources
OAuth providers (Google, GitHub, etc.)
Password authentication (custom)
Passkey/WebAuthn (biometrics)⚠️
Password Hashing
PostgreSQL native (pgcrypto)
Built-in PBKDF2
Other Features
Custom login/logout functions
Multiple auth schemes simultaneously
Role-based access control
Claims to PostgreSQL context
Claims to PostgreSQL parameters

⚠️ = Requires third-party integration

Token schemes: NpgsqlRest supports three distinct token formats:

  • Standard JWT Bearer: Industry-standard JSON Web Tokens
  • Microsoft Data Protection Bearer: Encrypted bearer tokens using ASP.NET Core Data Protection—a Microsoft proprietary format that encrypts the entire token payload
  • Encrypted Cookies: Session cookies encrypted with Data Protection, ideal for traditional web applications

Authentication sources: Users can authenticate via:

  • OAuth providers: External identity providers (Google, GitHub, Microsoft, etc.)
  • Password authentication: Either using PostgreSQL's native password hashing (via pgcrypto) or NpgsqlRest's built-in PBKDF2 implementation
  • Passkey/WebAuthn: Passwordless authentication using device biometrics (fingerprint, Face ID) or security keys—client device dependent

Passkey/WebAuthn support: NpgsqlRest includes built-in passkey authentication for passwordless login using device biometrics or PINs. NpgsqlRest handles the WebAuthn protocol (CBOR parsing, signature verification) while your PostgreSQL functions control user management and credential storage. PostgREST has no passkey support. Supabase does not offer native passkey support—users must integrate third-party services like Corbado or Descope to add passkeys to their Supabase applications.

NpgsqlRest also offers claims-to-parameters mapping - user claims (user ID, roles, custom claims) are automatically injected as function parameters by configurable name matching, with type safety enforced by PostgreSQL. PostgREST and Supabase only support accessing claims via current_setting() or auth.jwt() context functions, requiring manual casting within your SQL code.

PostgREST only supports JWT - you need an external auth server like GoTrue (which is what Supabase uses).

File Handling

FeatureNpgsqlRestPostgRESTSupabase
File uploads
Image uploads with validation
PostgreSQL Large Objects
File system storage
CSV file ingestion
Excel file ingestion
CSV export
Excel (.xlsx) export (streaming)
HTML table rendering
Row-by-row processing
Upload metadata to functions

NpgsqlRest provides comprehensive file handling including:

  • Image uploads with format validation (JPEG, PNG, GIF, WebP, etc.)
  • CSV/Excel ingestion with row-by-row processing through PostgreSQL functions
  • PostgreSQL Large Objects for storing files directly in the database
  • Combined handlers (multiple storage backends in a single transaction)
  • Streaming Excel (.xlsx) exports with zero allocations and constant memory (~80KB), powered by SpreadCheetah. One annotation (@table_format = excel) turns any function into a downloadable spreadsheet with native Excel types. PostgREST and Supabase only support CSV export—for Excel, you need external libraries or third-party services.

PostgREST has no file upload support. Supabase requires a separate Storage service.

Security and Infrastructure

FeatureNpgsqlRestPostgRESTSupabase
Application-level column encryption
Security headers middleware
Forwarded headers (reverse proxy)⚠️
Health check endpoints⚠️
PostgreSQL statistics endpoints

Application-level column encryption: NpgsqlRest provides transparent encrypt/decrypt annotations powered by ASP.NET Data Protection. Parameter values are encrypted before being sent to PostgreSQL, and result columns are decrypted before returning to the client — the database stores ciphertext while the API consumer sees plaintext. Useful for PII (SSN, medical records) without requiring pgcrypto or client-side encryption. PostgREST has no built-in encryption. Supabase provides Vault for managing secrets but not annotation-level column encryption.

Security headers: NpgsqlRest includes built-in middleware for HTTP security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Content-Security-Policy, Permissions-Policy, COOP, COEP, CORP). PostgREST and Supabase require reverse proxy configuration or application-level implementation.

Forwarded headers: NpgsqlRest has built-in middleware for processing X-Forwarded-For/Proto/Host headers with configurable trusted proxies and networks. PostgREST can read these headers via SQL but has no configuration for trusted proxy validation. Supabase handles this at their API gateway level.

Health check endpoints: NpgsqlRest provides /health, /health/ready (with PostgreSQL connectivity check), and /health/live endpoints for Kubernetes/Docker orchestration. PostgREST has /live and /ready via its Admin Server. Supabase has service-specific health checks but no unified application health endpoint.

PostgreSQL statistics: NpgsqlRest exposes /stats/routines, /stats/tables, /stats/indexes, and /stats/activity for monitoring PostgreSQL performance. PostgREST has no built-in stats endpoints (requires custom views). Supabase provides a Metrics API with ~200 PostgreSQL metrics (cloud only, not self-hosted).

Performance Features

FeatureNpgsqlRestPostgRESTSupabase
Response caching (memory)
Response caching (Redis)
Hybrid cache with stampede protection
Cache invalidation endpoints
Rate limiting
Multiple rate limit algorithms
Connection pooling
Command retry with backoff
Multi-host failover
Request compression
Response compression (Gzip/Brotli)

NpgsqlRest includes enterprise-grade performance features:

  • Three caching modes: Memory, Redis, and Hybrid with stampede protection
  • Four rate limiting algorithms: Fixed window, sliding window, token bucket, concurrency
  • Automatic retry with exponential backoff for transient failures
  • Multi-host failover with read replica support

Real-Time Capabilities

FeatureNpgsqlRestPostgRESTSupabase
Server-Sent Events (SSE)
WebSockets
PostgreSQL RAISE streaming
PostgreSQL LISTEN/NOTIFY
Broadcast to subscribed clients
Event scoping (authorize/matching/all)

NpgsqlRest uses Server-Sent Events for real-time streaming, which is simpler than WebSockets and works through standard HTTP. PostgreSQL's RAISE INFO/NOTICE/WARNING statements stream directly to connected clients - no message brokers or LISTEN/NOTIFY infrastructure needed. See the Real-Time Chat example.

Advanced Features

FeatureNpgsqlRestPostgRESTSupabase
Per-endpoint configuration in DB
Reverse proxy mode
Proxy to external services
HTTP calls from PostgreSQL
HTTP call retry logic
Server-side resolved parameters
Custom response headers
Request header forwarding
Per-endpoint timeouts
Per-endpoint caching policies
Per-endpoint rate limiting
Per-endpoint retry strategies
Parameter validation
Raw (non-JSON) responses
Error code mapping
CORS configuration
HTTPS/TLS

NpgsqlRest's reverse proxy feature allows PostgreSQL functions to define upstream services, enabling patterns like:

  • Proxying to AI services (OpenAI, Anthropic) with response caching
  • API aggregation from multiple external sources
  • Response transformation and enrichment

Observability

FeatureNpgsqlRestPostgRESTSupabase
Structured logging
Log to file
Log to PostgreSQL
OpenTelemetry
Request tracing
Execution ID tracking
Sensitive parameter obfuscation

NpgsqlRest uses Serilog with multiple output targets: console, file (with rotation), PostgreSQL table, and OpenTelemetry for distributed tracing.

Configuration Approach

NpgsqlRest: SQL Comments

sql
sql
-- Define endpoint with custom path and authentication
create function api.get_user(p_id int)
returns setof user_info
language sql
begin atomic;
select id, name, email, role from users where id = p_id;
end;

comment on function api.get_user(int) is '
HTTP GET /users/{p_id}
@authorize admin, user
@cached
@cache_expires_in 300
@rate_limiter_policy standard
';

Everything is configured through SQL comments directly on your functions and tables. This keeps API configuration close to the implementation and version-controlled with your schema.

This is a unique NpgsqlRest feature: every endpoint can be individually configured with its own caching policy, rate limiting, authentication requirements, timeout, retry strategy, and more—all stored in the database alongside your code. PostgREST and Supabase apply configuration globally or require external tools for per-endpoint customization.

PostgREST: External Configuration + RLS

sql
sql
-- PostgREST relies on Row Level Security
create policy "Users can view own data"
  on users for select
  using (auth.uid() = id);

PostgREST uses a combination of configuration files and PostgreSQL Row Level Security policies. Custom paths and advanced routing require an API gateway like Kong.

Supabase: Dashboard + RLS + Edge Functions

Supabase uses a web dashboard for most configuration, RLS for authorization, and Edge Functions (Deno) for custom logic. More moving parts, but provides a visual interface.

Deployment Comparison

NpgsqlRest

bash
bash
# Option 1: Direct download (30MB)
wget https://github.com/NpgsqlRest/NpgsqlRest/releases/latest/download/npgsqlrest-linux64
chmod +x npgsqlrest-linux64
./npgsqlrest-linux64 --connection "Host=localhost;Database=mydb;Username=api"

# Option 2: Docker
docker run -p 8080:8080 vbilopav/npgsqlrest:latest \
  --connection "Host=host.docker.internal;Database=mydb;Username=api"

# Option 3: NPM
npm install -g npgsqlrest
npx npgsqlrest --connection "..."

Single binary, zero dependencies. Works on Windows, Linux (x64/ARM64), and macOS.

PostgREST

bash
bash
# Download and run
wget https://github.com/PostgREST/postgrest/releases/latest/download/postgrest-linux-static-x64.tar.xz
tar xf postgrest-linux-static-x64.tar.xz
./postgrest postgrest.conf

# Docker
docker run -p 3000:3000 postgrest/postgrest

Similar simplicity, but requires external services for authentication and file handling.

Supabase Self-Hosted

bash
bash
# Clone the Docker setup
git clone https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
docker compose up -d

Supabase self-hosting requires Docker Compose with 7+ containers: PostgreSQL, PostgREST, GoTrue, Realtime, Storage, Kong, Studio, and more. More complex to maintain and scale.

When to Choose Each

Choose NpgsqlRest When:

  • You want a self-hosted platform - API, static files, auth, and code generation in one binary
  • Performance is critical - 2.6x faster than PostgREST under load
  • You want function-first API design - Business logic in PostgreSQL functions, not client-side query composition
  • You need enterprise features - Caching (memory/Redis/hybrid), rate limiting, retry logic, multi-host failover
  • You need file handling - Upload images, process CSV/Excel, store as Large Objects
  • You want real-time without WebSocket complexity - SSE with PostgreSQL RAISE statements
  • You prefer simple deployment - Single binary on any cloud server (AWS, DigitalOcean, Hetzner, etc.)
  • You use TypeScript - Auto-generated type-safe clients with full type definitions
  • You want custom URL paths - /users/{id} instead of /rpc/get_user?id=1
  • You need template-based pages - Static HTML with claim substitution (user name, email, role)

Choose PostgREST When:

  • You want a proven, mature solution - PostgREST has been around since 2014
  • You need flexible client-side queries - Resource embedding, filtering, aggregates, pagination
  • You want GraphQL-like query composition - Clients can request exactly the data they need
  • You're already using Row Level Security - PostgREST integrates well with RLS
  • Your API is table/view-centric - Most of your endpoints map directly to tables
  • You prefer Haskell's correctness guarantees - PostgREST is written in Haskell

Choose Supabase When:

  • You want managed cloud hosting - Let Supabase handle infrastructure
  • You need the Studio UI - Visual database management and API exploration
  • You want social login out of the box - Google, GitHub, etc. pre-configured
  • Your team is less experienced with PostgreSQL - More guardrails and documentation
  • You're building a prototype quickly - Fastest time-to-market for simple apps
  • You prefer a visual dashboard - Configure and explore your API visually

Migration Considerations

From PostgREST to NpgsqlRest

  1. Functions work identically - Both expose PostgreSQL functions as endpoints
  2. Add SQL comments for configuration - Replace external config with inline annotations
  3. Replace RLS with function-level auth - Or keep RLS and add authorize annotations
  4. Gain features - Caching, rate limiting, file uploads now available

From Supabase to NpgsqlRest

  1. Keep your PostgreSQL schema - It's still just PostgreSQL
  2. Replace GoTrue with built-in auth - JWT, encrypted Bearer/Cookie, OAuth, Passkey/WebAuthn
  3. Replace Storage with NpgsqlRest uploads - File system or Large Objects
  4. Replace Realtime with SSE - Simpler protocol, works through standard HTTP
  5. Move Edge Functions to PostgreSQL - Or use reverse proxy for external calls

Conclusion

CriteriaWinner
Raw PerformanceNpgsqlRest (2.6x faster)
Self-Hosted PlatformNpgsqlRest (single binary)
Table/View Query FlexibilityPostgREST / Supabase
Function-Based APIsNpgsqlRest
Per-Endpoint ConfigurationNpgsqlRest
Static Files + Template ParsingNpgsqlRest
Frontend Code GenerationNpgsqlRest / Supabase
Deployment SimplicityNpgsqlRest / PostgREST (tie)
Authentication OptionsNpgsqlRest
Passkey/WebAuthnNpgsqlRest (only native support)
File HandlingNpgsqlRest
Excel Export (native .xlsx)NpgsqlRest (only native support)
Enterprise Features (caching, rate limiting)NpgsqlRest
Column Encryption (encrypt/decrypt)NpgsqlRest (only native support)
Security HeadersNpgsqlRest (only built-in)
Health Checks (Kubernetes/Docker)NpgsqlRest / PostgREST
PostgreSQL Statistics EndpointsNpgsqlRest / Supabase
Custom Types / Nested JSONAll three (different strengths)
Real-TimeSupabase (WebSockets) / NpgsqlRest (SSE)
Managed HostingSupabase
Visual DashboardSupabase
Maturity/CommunityPostgREST / Supabase

Each tool excels in different areas:

NpgsqlRest is a complete self-hosted platform ideal when you need enterprise-grade features (caching, rate limiting, multi-host failover, retry logic), high performance, custom URL paths, file handling, or prefer keeping your API logic in PostgreSQL functions. Beyond API generation, it serves static files with template parsing, generates TypeScript clients, and includes built-in authentication—all in a single ~30MB binary you can deploy on any cloud server. A unique strength is per-endpoint configuration stored in the database—each function can have its own caching, rate limiting, timeout, and authentication rules defined via SQL comments, version-controlled alongside your schema.

PostgREST shines for flexible client-side queries with its GraphQL-like resource embedding, 28+ filtering operators, aggregates, and pagination. It's the right choice when your API consumers need to compose their own queries against tables and views. PostgREST is API-only—you'll need additional services for auth, static files, and file uploads.

Supabase is ideal when you want managed cloud hosting with a visual dashboard—especially for teams that prefer not to manage infrastructure. While both NpgsqlRest and Supabase are platforms, Supabase requires 7+ services for self-hosting whereas NpgsqlRest is a single binary.


Comments