pREST v2.0.0 is the first stable v2 release of pREST, the open-source PostgreSQL REST API for Go teams. It ships multi-database registry support, hardened connection management, and configuration resilience on top of the hexagonal architecture introduced in the release candidates. v2.1.0 adds a read-only MCP endpoint at /_mcp so agents can query Postgres through pREST’s existing auth and ACL — without a separate MCP process. See v2.0.0 and v2.1.0.
pREST v2 series: Architecture (rc6) → This post (v2.0.0 / v2.1.0 GA) → MCP tutorial
What is pREST?
pREST is an open-source Go tool that turns PostgreSQL into a REST API. It exposes tables and custom SQL scripts over HTTP with low-code CRUD, authentication, and access control — a lightweight alternative for teams that want a Postgres-backed API without writing every handler by hand. pREST targets Go backends, existing Postgres applications, and teams migrating from ad-hoc REST layers to a config-driven approach.
Who should upgrade to v2
- Multi-tenant SaaS — route each tenant to a registered database alias with per-tenant ACL
- Multi-cluster operations — one pREST deployment fronting Postgres clusters on different hosts
- Agent-safe database access — v2.1.0 MCP exposes read-only, permission-aware queries to Cursor, Claude, or custom agents
- Teams on rc6 — incremental upgrade to GA without a second architectural rewrite
Table of Contents
- The v2 story in three acts
- v2.0.0 GA — what’s new since rc6
- Multi-database in practice
- v2.1.0 — Native MCP over HTTP
- What carried over from rc6
- Upgrading
- FAQ
- Also from Insurgency Labs
The v2 story in three acts
Version 2 is a major overhaul of pREST’s internals. The story breaks into three milestones:
- Release candidates (rc6) — hexagonal architecture, Adapter port decomposition, dependency-injected controllers. Covered in depth in the prior architecture post.
- v2.0.0 GA — production hardening: multi-database registry, PrestConf and connection management, configuration resilience.
- v2.1.0 — agent integration: read-only MCP over HTTP on the same server.
If you followed the rc6 cycle, v2.0.0 and v2.1.0 are incremental on top of that foundation — not a second rewrite.
v2.0.0 GA — what’s new since rc6
Three merged PRs ship between v2.0.0-rc6 and v2.0.0:
Multi-database registry — PR #973
The headline feature for v2.0.0. pREST can route requests to multiple Postgres clusters through a database registry:
- Alias-based routing — the first URL path segment selects a registered database alias (e.g.
GET /tenant-a/public/users) - Multi-cluster mode — each alias can point to a different host, port, and credentials
- Database-aware permissions —
access.tablesentries can scope rules per alias and schema - Readiness endpoint —
GET /_readypings the default database and every registered alias
PrestConf and connection management — PR #972
- Config-driven adapter startup with clearer errors for non-Postgres adapters
- Connection pooling with
singleflightdeduplication logsafepackage redacts database credentials in error logs- Per-adapter statement caching and context-aware health checks
- Reduced reliance on global runtime state
Configuration resilience — PR #974
- Malformed or missing config files fall back to safe defaults instead of blocking startup
- JWT misconfiguration disables auth with warning logs (non-fatal)
- Invalid structured config keys warn and default to zero values
Multi-database in practice
pREST uses the first URL path segment as the database selector for CRUD, catalog, and script routes.
| Mode | When | {database} in URL |
Connection target |
|---|---|---|---|
| Legacy multi-DB | No registry configured | Postgres database name | Same host; dbname = path segment |
| Registry multi-cluster | [[databases]] or env registry set |
Registered alias | Per-profile host, port, credentials |
Example routes:
GET /tenant-a/public/users
GET /tenant-a/public
GET /_ready
Multi-tenant PostgreSQL REST API
A common pattern: register one alias per tenant (tenant-a, tenant-b) pointing at isolated Postgres databases or schemas. URL routing stays consistent (/{alias}/{schema}/{table}), while access.tables enforces per-tenant read/write rules. Kubernetes readiness probes use /_ready to confirm every alias is reachable before accepting traffic.
Registry configuration supports TOML for local development and indexed environment pairs for production:
DATABASE_ALIAS_1=tenant-a
DATABASE_URL_1=postgres://user:pass@cluster-a.example.com:5432/app_a?sslmode=require
Permission rules can scope per alias:
[[access.tables]]
database = "tenant-a"
schema = "public"
name = "users"
permissions = ["read"]
Pools are keyed by connection URI; aliases sharing the same URI share a pool. Plan connection budgeting as replicas × aliases × pg.maxopenconn per cluster.
Full configuration examples are in the pREST README.
v2.1.0 — Native MCP over HTTP
v2.1.0 adds a read-only MCP-compatible endpoint at /_mcp on the same server that serves catalog, CRUD, and script routes (PR #977, closes #959).
Model Context Protocol (MCP) is the open standard agents use to discover and call tools. pREST implements MCP as HTTP JSON-RPC on the existing server — no separate MCP daemon, no extra port. The MCP surface inherits pREST’s deployment model, database routing, identifier validation, and access control. When auth is enabled, /_mcp requires authentication like other protected routes. Supported JSON-RPC methods: initialize, tools/list, tools/call. Tools include catalog discovery (prest.list_databases, prest.list_schemas, prest.list_tables) and schema-aware per-table selects.
For step-by-step setup — Docker quick start, curl walkthrough, Cursor and Claude Desktop configuration — see the pREST MCP server tutorial.
What carried over from rc6
Everything from the release candidate line remains in v2.0.0 and v2.1.0:
- Hexagonal architecture, Adapter port split, DI controllers (#968)
- JWT auth bypass fix (#960)
- OR clause support (#958)
- GoReleaser Docker images (#953), Go 1.26, split unit/integration CI
- Structured logging via
slog(#950)
See the architecture post for the Adapter decomposition and request-flow details.
Upgrading
From v1.x: expect breaking changes — v2 module path (github.com/prest/prest/v2), config shape updates, bcrypt as the default password encryption. Test in staging before production.
From rc6: incremental upgrade. Add multi-database registry config if you need multi-cluster routing, then move to v2.1.0 when you want MCP.
pREST vs PostgREST: both expose PostgreSQL over REST. PostgREST is Haskell-based and schema-driven; pREST is Go-native with config-driven routes, custom SQL scripts, and — in v2 — a database registry and built-in MCP endpoint. Choose based on language ecosystem, deployment model, and whether you need multi-cluster aliases or agent-facing read tools.
Docker:
docker pull prest/prest:v2.0.0
docker pull prest/prest:v2.1.0
v2.1.0 is tagged on GitHub; formal release assets may follow — pin the tag. Open issues or discussions on prest/prest for migration questions.
FAQ
What is pREST?
pREST is an open-source Go tool that turns PostgreSQL into a REST API. It provides low-code CRUD over tables, custom SQL scripts, authentication, and access control — aimed at Go teams building on existing or new Postgres databases.
How is pREST v2 different from v1?
v2 introduces hexagonal architecture with dependency-injected controllers, a multi-database registry, hardened PrestConf connection management, configuration resilience, and — in v2.1.0 — a read-only MCP endpoint. v2 also bumps the Go module path to github.com/prest/prest/v2 and changes several config defaults.
What is multi-database support in pREST?
Multi-database support lets pREST route HTTP requests to different Postgres clusters using registered aliases. The first URL path segment selects the alias; permissions, connection pools, and health checks are alias-aware. Configure aliases via TOML or environment variables.
What is the MCP endpoint in v2.1.0?
v2.1.0 exposes a read-only MCP-compatible HTTP endpoint at /_mcp. It supports JSON-RPC methods initialize, tools/list, and tools/call for catalog discovery and schema-aware table reads. Auth and ACL from the REST API apply to MCP requests.
Is pREST an alternative to PostgREST?
Both are PostgreSQL REST API layers. PostgREST is Haskell-based and auto-generates routes from your schema. pREST is Go-native, supports custom SQL scripts and multi-cluster registry routing, and adds a built-in MCP endpoint in v2.1.0. The right choice depends on your stack and operational requirements.
Should I upgrade from v1 or rc6?
From v1.x, plan for breaking changes and test in staging. From rc6, upgrade is incremental — v2.0.0 for multi-DB and production hardening, v2.1.0 for MCP. Pin Docker tags or binaries to the specific version you validate.
Also from Insurgency Labs
Both pREST MCP and DeliveryCompass follow a read-only, permission-aware model — pREST for Postgres queries through /_mcp, DeliveryCompass for GitHub PR delivery metrics through a read-only dashboard for engineering managers. See the DeliveryCompass overview. Free during Early Access; not a Jira replacement.