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

pREST v2.2.0 embeds a Studio UI in the prestd binary, so one binary now serves REST, MCP and Studio. It also lets custom queries live in the database and gives TimescaleDB a tested path.

pREST turns a Postgres database into a production-ready REST API. Since v2.1, it’s also a read-only MCP endpoint for AI agents. Here’s what shipped in v2.2.0 and what I’d try first.

Table of Contents

• What v2.2.0 gives you
• How to get v2.2.0
• Step 1: open pREST Studio
• Step 2: store custom queries in the database
• Step 3: check TimescaleDB reads
• What else ships in v2.2.0
• FAQ
• Links

What v2.2.0 gives you

Point pREST at your schema and you get CRUD, custom SQL routes, auth and ACL without hand-writing a backend. v2.2.0 makes that surface easier to use day to day:

• pREST Studio, a self-hosted UI embedded in the prestd binary and served at /_studio/.
• Custom queries stored in a prest_queries table and managed over HTTP.
• First-class TimescaleDB support, with integration tests, Compose stacks and docs.

How to get 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.

Step 1: open pREST Studio

Upgrade and open /_studio/ against a non-prod database. It’s the fastest way to feel the release.

http://localhost:3000/_studio/

There’s 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. It has four views:

• Overview shows health, build metadata, and REST/MCP availability.
• Data Explorer browses databases, schemas and tables, previews rows, and copies URLs and curl.
• REST Explorer builds GET requests with pREST query params and inspects responses.
• MCP Explorer lists tools, generates forms from JSON Schema, invokes them and keeps in-memory history.

It’s on by default. Turn it off with PREST_STUDIO_ENABLED=false, and /_studio/ returns 404.

Studio doesn’t invent a new auth model. It rides on existing JWT, ACL and database permissions. Tokens stay in memory by default, and 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. That’s especially useful when you’re wiring MCP into Cursor or Claude.

Step 2: store custom queries in the database

If you already use custom SQL routes, try queries.storage = "database" with import_on_startup. Then see how registry and ACL fit your deploy model.

Custom queries used to mean SQL files on disk under queries.location. That still works and stays 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 and enforce per-script ACL with queries.restrict. Execution stays on the familiar /_QUERIES/{location}/{script} paths.

For multi-instance or containerized setups, this is a meaningful ops win. Query definitions sit next to the data instead of being baked into every image as .sql files.

Step 3: check TimescaleDB reads

If you run Timescale, run through the integration guide. Confirm hypertable reads behave as expected.

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

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.

What else ships in v2.2.0

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.

FAQ

What is pREST Studio?

It’s a self-hosted UI embedded in the prestd binary and served at /_studio/. It has an Overview, a Data Explorer, a REST Explorer and an MCP Explorer. It’s a same-origin client of your existing REST and MCP APIs.

How do I turn off pREST Studio?

Set PREST_STUDIO_ENABLED=false. Studio is on by default, and once disabled, /_studio/ returns 404.

Can I edit data or run SQL in pREST Studio?

Not yet. The MVP is deliberately read-oriented, with no SQL editor, mutations or ACL UI. It uses your existing JWT, ACL and database permissions.

Can pREST store custom queries in the database?

Yes, since v2.2.0. Set queries.storage = "database" to keep scripts in a prest_queries table. With register_enabled = true and auth configured, admins manage them through /_QUERIES/registry. Filesystem storage stays the default.

Does pREST support TimescaleDB?

Yes. TimescaleDB has long worked because it’s Postgres under the hood. v2.2.0 adds dedicated integration tests, Compose stacks, and docs for hypertables and time-series workloads.

Links

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