Faucet vs PostgREST: Which Database REST API Generator Should You Use in 2026?
TL;DR: PostgREST is a mature, battle-tested tool for turning PostgreSQL into a REST API — but it only supports PostgreSQL, has no admin UI, and requires deep SQL expertise for authorization. Faucet supports seven databases (PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake, MariaDB), includes a built-in web admin UI, ships with role-based access control, generates OpenAPI 3.1 specs, and provides a native MCP server for AI agent integration — all from a single Go binary.
What Is PostgREST?
PostgREST is an open-source tool written in Haskell that automatically generates a RESTful API from an existing PostgreSQL database. It introspects the database schema at runtime and exposes tables, views, and stored functions as REST endpoints with zero code generation. PostgREST has been in active development since 2014, currently sits at version 14.5, and has earned approximately 26,400 GitHub stars. Supabase uses PostgREST as its core REST API layer and has contributed over $250,000 in sponsorship, making PostgREST one of the best-funded tools in this category.
What Is Faucet?
Faucet is an open-source, single-binary server that turns any SQL database into a secure, governed REST API with role-based access control and native MCP support for applications and AI agents.
Faucet is written in Go and supports PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Snowflake, and SQLite — plus cloud-hosted variants like Amazon RDS, Aurora, Azure SQL, Oracle Cloud (OCI), Supabase, Neon, and PlanetScale. Where PostgREST focuses exclusively on PostgreSQL, Faucet takes a multi-database approach: one binary, one command, any SQL database.
# Connect Faucet to any SQL database — one command
faucet serve --dsn "postgres://user:pass@localhost:5432/mydb"[VISUAL: Architecture diagram showing PostgREST connecting only to PostgreSQL on the left, versus Faucet connecting to PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake, and MariaDB on the right. Both generate REST APIs consumed by web apps, mobile apps, and (for Faucet only) AI agents via MCP. Use Mermaid.]
Feature-by-Feature Comparison
The following table compares Faucet and PostgREST across the dimensions that matter most when choosing a database REST API generator.
| Feature | Faucet | PostgREST |
|---|---|---|
| Supported databases | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, Snowflake | PostgreSQL only |
| Language / runtime | Go (single static binary) | Haskell (GHC compiled) |
| OpenAPI spec | OpenAPI 3.1 (auto-generated) | OpenAPI 2.0 (built-in); 3.1 in progress |
| Admin UI | Embedded Preact web dashboard | None |
| Authentication | API key + JWT | JWT only |
| Authorization | Built-in RBAC with table and field-level permissions | PostgreSQL Row Level Security (RLS) |
| MCP server | Native, built-in | Not available |
| Stored procedure support | Yes | Yes (via RPC endpoints) |
| Batch operations | Yes | Yes |
| Resource embedding | Related record retrieval | Foreign key-based nested responses |
| Query filtering | Standard query parameters | Rich operator set (eq, gt, lt, like, ilike, fts, and/or/not) |
| Schema-based API versioning | — | Yes (expose different schemas as different API versions) |
| Deployment | Homebrew, Docker, GitHub releases, curl-to-install | Pre-built binaries, Docker, Homebrew, Nix |
| Memory footprint | 20–50 MB | Varies (Haskell GHC runtime) |
| Cold start | < 100 ms | Fast (single binary) |
| License | MIT | MIT |
| GitHub stars | Early stage | ~26,400 |
| Primary sponsor | Independent | Supabase ($250K+) |
Database Support: One Database vs Seven
PostgREST’s single most significant constraint is that it supports PostgreSQL and nothing else. The name itself makes this clear. If your organization runs MySQL, SQL Server, Oracle, SQLite, or Snowflake — or any combination of databases — PostgREST cannot help.
Faucet supports seven SQL databases from a single binary:
- PostgreSQL (including Amazon RDS, Aurora, Supabase, Neon)
- MySQL (including MariaDB, PlanetScale, Amazon RDS)
- SQL Server (including Azure SQL)
- Oracle (including OCI, Amazon RDS, Azure)
- SQLite
- Snowflake
This matters in practice. Most organizations do not run a single database engine. A company might use PostgreSQL for its primary application, MySQL for a legacy service, and Snowflake for analytics. With Faucet, one tool covers all of them. With PostgREST, you need a completely different solution for every non-PostgreSQL database.
# Faucet works with any supported database — same command, same API format
faucet serve --dsn "postgres://user:pass@localhost:5432/app_db"
faucet serve --dsn "mysql://user:pass@localhost:3306/legacy_db"
faucet serve --dsn "sqlserver://user:pass@localhost:1433?database=erp"
faucet serve --dsn "sqlite:///path/to/analytics.db"Authentication and Authorization
PostgREST and Faucet take fundamentally different approaches to security.
PostgREST: JWT + PostgreSQL RLS
PostgREST delegates authentication and authorization almost entirely to PostgreSQL. Clients authenticate by sending a JWT token in the Authorization header. PostgREST verifies the token using a configured secret or public key, then uses SET ROLE to impersonate the role specified in the JWT’s role claim. Authorization is handled through PostgreSQL’s built-in Row Level Security (RLS) policies and GRANT statements.
This approach is powerful — you get per-row, per-column access control using the full expressiveness of SQL — but it comes with a steep learning curve. You must:
- Design database roles and grants carefully
- Write RLS policies in SQL for every table
- Deploy a separate service to issue and manage JWTs (PostgREST does not handle login, user registration, or token issuance)
- Be comfortable debugging authorization logic in SQL
For teams with deep PostgreSQL expertise, this model is elegant. For everyone else, it is a significant barrier to entry.
Faucet: Built-In RBAC
Faucet ships with a built-in role-based access control (RBAC) system that includes table-level and field-level permissions. Faucet supports both API key and JWT authentication without requiring an external auth provider for basic use cases. Permissions are configured through the admin UI or API — no SQL expertise required.
Faucet is best suited for teams that want a working, secure API in minutes without writing authorization logic in SQL.
[VISUAL: Side-by-side comparison: on the left, PostgREST’s auth flow showing JWT issuance by external provider → PostgREST verifies → SET ROLE → PostgreSQL RLS policy evaluation. On the right, Faucet’s auth flow showing API key or JWT → Faucet RBAC engine → table/field permission check → query execution. Use Mermaid.]
Admin UI and Developer Experience
PostgREST does not include a web interface of any kind. Configuration is done via a config file or environment variables. To explore the API, developers must use external tools like Swagger UI (pointed at PostgREST’s OpenAPI 2.0 output), curl, or Postman. There is no built-in way to manage users, view permissions, or inspect the database schema through a browser.
Faucet includes an embedded Preact web admin UI that runs inside the same binary — no separate frontend process, no additional dependencies. The admin UI provides:
- Database schema browsing
- API endpoint exploration and testing
- Role and permission management
- Configuration without editing files
This reduces the operational complexity of running Faucet in production. There is one process to manage, one port to expose, and one URL to bookmark.
OpenAPI Specification
PostgREST generates an OpenAPI 2.0 (Swagger) specification at its root path. While functional, OpenAPI 2.0 is the older standard, and many modern API tools and code generators expect OpenAPI 3.x. A community effort (postgrest-openapi) is working on OpenAPI 3.1 support, but this has not yet been merged into the core PostgREST binary.
Faucet generates OpenAPI 3.1 specifications natively. OpenAPI 3.1 is fully aligned with JSON Schema, supports webhooks, and is the current industry standard for API documentation.
MCP Server: AI Agent Integration
Faucet includes a native MCP (Model Context Protocol) server, enabling AI agents and LLMs to interact with your database directly through a standardized protocol. This means tools like Claude, ChatGPT, and other AI assistants can query and understand your data without custom integration code.
PostgREST does not have MCP support. To connect an AI agent to a PostgREST API, you would need to build a custom integration layer or wrapper.
As AI-assisted development and autonomous agents become more prevalent, native MCP support is an increasingly meaningful differentiator.
Architecture and Performance
PostgREST
PostgREST is compiled Haskell running on the Warp HTTP server, which is consistently among the fastest HTTP servers in benchmarks. PostgREST delegates JSON serialization to PostgreSQL itself (using json_agg and to_json), which avoids an extra serialization step in application code. The Hasql database driver uses PostgreSQL’s binary protocol for efficient data transfer.
PostgREST uses GHC green threads for concurrency, which are lightweight and handle high connection counts efficiently.
PostgREST’s performance is excellent for its use case. The Haskell runtime, however, means that the contributor pool is smaller, cross-compilation is harder, and Alpine Linux deployments are discouraged due to a known GHC memory leak.
Faucet
Faucet is written in Go with the Chi router, sqlx for database access, and Go’s native concurrency model (goroutines). Faucet achieves sub-millisecond routing, connection pooling, non-blocking concurrency, a cold start under 100 ms, and a memory footprint of 20–50 MB.
Go’s compilation model produces truly static binaries that cross-compile to any OS/architecture trivially. This makes distribution simpler — Faucet is available via Homebrew, Docker Hub (faucetdb/faucet), GitHub releases, and curl-to-install.
PostgREST’s Unique Strengths
PostgREST is not without advantages. Fair comparison demands acknowledging where PostgREST excels:
- Mature and battle-tested. PostgREST has been in production at scale since 2014. Supabase routes millions of API requests through PostgREST daily. Faucet is a newer project.
- Rich query filtering. PostgREST’s URL-based query language supports operators like
eq,gt,lt,like,ilike,in,is,fts(full-text search), logical combinators (and,or,not), and range queries. This is one of the most expressive REST query syntaxes available. - Schema-based API versioning. PostgREST can expose different PostgreSQL schemas as different API versions, enabling non-breaking API evolution at the database level.
- Resource embedding. PostgREST’s foreign key-based embedding lets you retrieve nested, related data in a single request — effectively getting GraphQL-like joins over REST.
- Community and ecosystem. With approximately 26,400 GitHub stars and Supabase’s backing, PostgREST has a large community, extensive documentation, and a proven track record.
- PostgreSQL-native authorization. For teams already fluent in PostgreSQL RLS, PostgREST’s auth model is genuinely powerful — per-row, per-column, per-user access control using the full expressiveness of SQL.
When to Choose PostgREST
PostgREST is the right choice when:
- Your organization runs PostgreSQL exclusively with no plans to support other databases
- Your team has strong PostgreSQL expertise and is comfortable writing RLS policies, functions, and grants
- You want a proven, mature tool with a decade of production usage
- You need advanced query filtering, resource embedding, or schema-based API versioning
- You are already using Supabase (which bundles PostgREST internally)
When to Choose Faucet
Faucet is the right choice when:
- You need to expose multiple database types (PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake) as REST APIs
- You want built-in RBAC without writing authorization logic in SQL
- You need a web admin UI for configuration, schema browsing, and API exploration
- You want OpenAPI 3.1 spec generation (not 2.0)
- You need MCP support for AI agent and LLM integration
- You want a single Go binary that is easy to build, deploy, and contribute to
- You prefer a simpler setup experience — connect a database, get an API, manage permissions in a UI
Getting Started with Faucet
Faucet requires one command to install and one command to run:
# Install via Homebrew
brew install faucetdb/tap/faucet
# Or pull the Docker image
docker pull faucetdb/faucet
# Connect to your database and start serving
faucet serve --dsn "postgres://user:pass@localhost:5432/mydb"
# Your API is live — query it immediately
curl http://localhost:8080/api/v1/users?limit=10Faucet introspects your database schema, generates REST endpoints for every table, and serves an OpenAPI 3.1 spec — all in under a second.
[VISUAL: Terminal recording (animated GIF) showing: brew install faucetdb/tap/faucet → faucet serve --dsn "postgres://..." → server startup output showing tables discovered → curl request with JSON response. Demonstrate the zero-to-API experience in ~15 seconds.]
Frequently Asked Questions
Is PostgREST free and open source?
Yes. PostgREST is released under the MIT license and is completely free to use. Supabase is its primary sponsor but does not impose any licensing restrictions.
Can Faucet connect to the same databases PostgREST supports?
Yes. Faucet fully supports PostgreSQL, including cloud-hosted variants like Amazon RDS, Aurora, Supabase, and Neon. Faucet also supports MySQL, MariaDB, SQL Server, Oracle, SQLite, and Snowflake — databases that PostgREST cannot connect to.
Does PostgREST support AI agent integration (MCP)?
No. PostgREST does not include an MCP server or any built-in mechanism for AI/LLM integration. Faucet includes a native MCP server that allows AI agents to interact with your database through a standardized protocol.
Can I migrate from PostgREST to Faucet?
Yes. If you are currently using PostgREST with a PostgreSQL database, Faucet can connect to the same database and generate a REST API. The URL structure and query syntax differ, so API consumers will need to update their requests. Faucet’s built-in RBAC replaces the need for PostgreSQL RLS policies, though you can continue using RLS at the database level if desired.
Which tool has better performance?
Both tools are highly performant. PostgREST benefits from Haskell’s Warp server and PostgreSQL-native JSON serialization. Faucet achieves sub-millisecond routing with Go’s Chi router and connection pooling. For most workloads, the performance difference between the two is negligible compared to the database query time itself. Choose based on features and database support rather than raw throughput.