pREST (PostgreSQL + REST) is a production-ready, MIT-licensed Go service that exposes an instant REST API and a read-only Model Context Protocol (MCP) endpoint on top of any existing or new PostgreSQL database, built for teams that want CRUD, custom SQL routes, authentication and access control without hand-writing a backend.

What it is

pREST, also published as pRESTd, is a Go application that sits in front of a PostgreSQL database of version 9.5 or higher and turns its schemas and tables into HTTP resources. It is distributed as a Docker image, a Homebrew formula named prestd, and an installable Go package, with configuration supplied through PREST_PG_URL, the pg.* keys, or DATABASE_URL. Alongside the REST surface it serves MCP over HTTP, documented for AI clients such as Cursor and Claude, and it supports working against more than one database at a time. Full documentation lives at docs.prestd.com, with the project homepage at prestd.com.

The concrete problem it solves is the hand-written backend that normally has to be built and maintained before any application can read or write its own data. Instead of writing and deploying controllers, models, authentication plumbing and authorization rules for each table, a team points pREST at the database it already has and calls GET /{database}/{schema}/{table} to obtain CRUD behaviour immediately. Where the generated routes are not enough, custom SQL routes are defined as _QUERIES script templates, so the API layer is configured rather than compiled.

Key capabilities

• Instant CRUD over HTTP against existing tables, addressed as GET /{database}/{schema}/{table}, with no hand-written handlers.
• Custom SQL routes built from _QUERIES script templates, using the helpers {{sqlVal "key"}} for a single value, {{sqlList "key"}} for a repeated query parameter such as ?tag=a&tag=b, and {{ident "key"}} for table or column names that cannot be bound.
• Parameter binding that carries values to Postgres out of band, so free-form input is never parsed as SQL.
• An interpolation screen that refuses values containing quotes, -- or ::, and refuses multi-word values containing a SQL keyword, failing the request with 400 when such a value is interpolated.
• Authentication and access control, listed as JWT in the project topics and as auth and ACL in the README.
• A read-only MCP endpoint over HTTP, documented under MCP over HTTP and aimed at AI clients including Cursor and Claude.
• Values and headers reachable from templates, including {{sqlVal "header.X-Application"}}, while credential headers such as Authorization and Cookie are always withheld.

Who uses it and how

• Teams that want a realtime RESTful API backed by Heroku Postgres can use the one-click Heroku deploy template, prest-heroku, rather than provisioning a separate backend service.
• Backend and microservice developers, per the project topics, run it as a container in Docker alongside their database and expose it as the data access tier.
• Organisations with an existing Postgres database adopt it to add an API surface without rewriting or migrating their schema.
• AI-assisted development workflows connect MCP clients such as Cursor and Claude through the MCP over HTTP endpoint for read-only access to data.
• Multi-tenant or multi-service deployments use the multi-database configuration to serve several databases from one instance.

Getting started

Install and run through Docker, the Homebrew formula prestd, or the Go toolchain as described in the Get pREST guide, then point it at Postgres with PREST_PG_URL, the pg.* keys, or DATABASE_URL before calling GET /{database}/{schema}/{table}. A Heroku one-click deploy option is also offered for a realtime RESTful API backed by Heroku Postgres.

How it compares

No comparable or competing products are named in the facts for this entry, and no list of paid products it replaces has been supplied, so it stands alone in this registry on that axis. It is MIT licensed and self-hostable, with the source and configuration under the operator's control.

When to use it — and when not to

A self-hoster must operate a PostgreSQL database of version 9.5 or higher and configure its connection details, authentication and ACL rules, so teams without Postgres operations experience should weigh that before adopting it. Anyone planning to interpolate user-supplied values into _QUERIES templates should expect the interpolation screen to reject ordinary search phrases containing words such as do, as or or with a 400, and should prefer binding through sqlVal and sqlList instead; the README also notes a contributor licence agreement for those who want to contribute code. The tracker currently carries 153 open issues, which is worth reviewing against specific requirements before a production rollout.

GET /{database}/{schema}/{table}

-- interpolated: screened, and rejected for values like 'compra do mes'
SELECT * FROM articles WHERE slug = '{{.slug}}'

-- bound: the caller's value arrives verbatim, whatever it contains
SELECT * FROM articles WHERE slug = {{sqlVal "slug"}}

make test-unit

# Postgres (full stack: default, auth, multicluster, queries) — also: make test-integration
make test-integration-postgres

# TimescaleDB (Timescale-specific E2E only)
make test-integration-timescaledb

docker compose -f integration/postgres/docker-compose.yml up -d --wait \
  postgres postgres-b db-init prestd prestd-multicluster prestd-auth prestd-queries
docker compose -f integration/postgres/docker-compose.yml run --rm --no-deps tests
docker compose -f integration/postgres/docker-compose.yml down -v --remove-orphans

docker build -t prest/prest:latest .

docker build \
  --build-arg VERSION=v1.0.0 \
  --build-arg COMMIT=hash \
  --build-arg DATE=2026-02-11 \
  -t prest/prest:latest .