Brought to you by Resonate

Durable Execution on Postgres

The protocol as a schema of stored procedures — one SQL file, and the database you already run becomes the server.

Apache 2.0Built by Resonate HQ

Every other way to get durable execution asks you to deploy something. Resonate HQ built one that doesn't: load a single SQL file into a Postgres 16+ database and the protocol lives inside it. Storage, queue, and timer are the database itself, with pg_cron driving all three. There is no process to run, no port to expose, and nothing to keep alive that isn't already alive.

Durable execution is a protocol, not a product

Postgres is now a durable-execution provider.

Any platform that can provide durable storage and an atomic compare-and-swap can implement the Resonate protocol — and Postgres does it natively. No layers borrowed from anywhere else: Postgres is the provider.

Why Postgres

The database is the server, not the storage.

Nothing to deploy beside it

The core server supports Postgres — you run a binary and Postgres holds its state. This is the other arrangement: there is no binary. Every protocol action is a stored procedure, so the thing you operate and the thing you back up are the same thing.

Timers and delivery, in-database

pg_cron drives the timers, so a durable sleep is a row with a deadline rather than a process waiting. Delivery pushes outward over pg_net, which means a suspended workflow occupies no compute at all — the invocation returns, and the database wakes the worker when there is something to do.

SQL-native

Workers talk to it in SQL, not HTTP.

There is no server process to host an HTTP interface, so workers reach the protocol through a single function over a database connection. That needs a client that speaks SQL — TypeScript has one today, and it pairs naturally with Postgres-hosted compute. If you need another language, tell us what your stack runs when you sign up.

psql -d yourdb -f resonate.sql

What's true today

No surprises. Here’s exactly where it stands.

License: Apache 2.0 — the same license as the core server, with no production-use restriction.
Maturity: The youngest of the three implementations. The protocol is implemented end to end and search works, but the repository ships no test suite of its own — only a conformance shim an external harness drives — and the tracker carries open correctness issues against task leasing and settlement. No production reference deployments yet. Sign up below to be among the first to run it in production.
SDK support: TypeScript only. The other Resonate SDKs have no client that can reach the protocol inside the database yet, and each is tracked as an open issue.
Authentication: Postgres's own. The schema revokes access from PUBLIC and ships a dedicated worker role with a minimal grant surface, so the database connection is the security boundary.
Requirements: Postgres 16+ with pg_cron, which drives every timer. pg_net or pgsql_http is optional and enables HTTP push delivery to your workers.
Ownership: Built and maintained by Resonate HQ. Postgres itself is unmodified — this is a schema you load, not a fork or a patched build.

Run durable execution inside your database.

We value your privacy