pREST v2.2.0: Studio, Database Queries, and TimescaleDB

Instant APIs, Now Easier to Explore

pREST turns a Postgres database into a production-ready REST API—and, since v2.1, a read-only MCP endpoint for AI agents. Point it at your schema and you get CRUD, custom SQL routes, auth, and ACL without hand-writing a backend.

v2.2.0 is about making that surface easier to use day to day: an embedded Studio UI, custom queries that live in the database, and solid TimescaleDB coverage. Here’s what shipped and why it matters.

pREST Studio

The headline feature is pREST Studio—a self-hosted UI embedded in the prestd binary and served at /_studio/:

http://localhost:3000/_studio/

No separate frontend process. The Vite build is embedded with go:embed, so runtime still means one binary: REST, MCP, and Studio together.

Studio is a same-origin client of the APIs you already have:

• Overview — health, build metadata, and REST/MCP availability
• Data Explorer — browse databases, schemas, and tables; preview rows; copy URLs and curl
• REST Explorer — build GET requests with pREST query params and inspect responses
• MCP Explorer — list tools, generate forms from JSON Schema, invoke them, keep in-memory history

It’s on by default. Turn it off with PREST_STUDIO_ENABLED=false (then /_studio/ returns 404).

Studio does not invent a new auth model. It rides on existing JWT, ACL, and database permissions. Tokens stay in memory by default; generated commands redact credentials unless you ask otherwise.

This MVP is deliberately read-oriented: no SQL editor, mutations, or ACL UI yet. The goal was a fast way to see what your instance exposes—especially useful when you’re wiring MCP into Cursor or Claude.

Database-Backed Custom Queries

Custom queries used to mean SQL files on disk under queries.location. That still works and remains the default (queries.storage = "filesystem").

v2.2.0 adds an alternative: store scripts in a prest_queries table and manage them over HTTP.

[queries]
storage = "database"
register_enabled = true
restrict = true
migrate_on_startup = true
import_on_startup = true

With register_enabled = true (and auth configured), admins get a registry API at /_QUERIES/registry for CRUD on stored queries. You can migrate existing filesystem scripts on startup, enforce per-script ACL with queries.restrict, and keep execution on the familiar /_QUERIES/{location}/{script} paths.

For multi-instance or containerized setups, keeping query definitions next to the data—instead of baking .sql files into every image—is a meaningful ops win.

TimescaleDB Support

TimescaleDB has long been usable with pREST because it’s Postgres under the hood. v2.2.0 makes that relationship first-class: dedicated integration tests, Compose stacks, and docs for hypertables and time-series workloads.

If you’re exposing sensor readings, metrics, or event streams over REST (or MCP), you can rely on a tested path instead of “it probably works.” Docs live at docs.prestd.com/integrations/timescaledb.

Docs, Postgres 18, and Release Plumbing

A few supporting changes round out the release:

• A fully documented sample prest.toml so new users aren’t guessing which knobs matter
• Docker Compose examples bumped to Postgres 18
• Dockerfile and GoReleaser updates so Studio assets land in published binaries and images
• Better coverage reporting for pull requests from forks

Getting v2.2.0

Binaries for Linux, macOS, Windows, and BSD are on the release page. Docker users can pull prest/prest:v2.2.0 (or latest once it tracks this tag).

Quick start is unchanged: point PREST_PG_URL (or pg.* / DATABASE_URL) at Postgres, start prestd, then hit:

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

Open /_studio/ to explore, or /_mcp if you’re connecting an AI client.

What I’d Try First

1. Upgrade and open /_studio/ against a non-prod database—it’s the fastest way to feel the release.
2. If you already use custom SQL routes, try queries.storage = "database" with import_on_startup and see how registry + ACL fit your deploy model.
3. If you run Timescale, run through the integration guide and confirm hypertable reads behave as expected.

Full changelog and assets: github.com/prest/prest/releases/tag/v2.2.0. Docs: docs.prestd.com.