Durable execution is a protocol, not a product

Run Resonate on what you already operate.

You don’t leave the stack you know and like — Resonate upgrades what you already run into a durable execution platform. Any platform with durable storage and an atomic compare-and-swap can implement the protocol — and it’s been proven across three storage paradigms already: SQL databases, a wide-column store, and a message broker. If yours has those two primitives, it already has what the protocol needs.

SQL

The core server

Postgres · SQLite · MySQL

The reference implementation. A single statically-linked binary that speaks the HTTP/JSON protocol, SQLite for local dev and Postgres or MySQL in production.

Apache 2.0

Get started

Message broker

Durable Execution on NATS

JetStream · NATS-native

An implementation on NATS JetStream where NATS is both storage and transport. NATS-native, not a drop-in HTTP server — it needs a NATS-aware client.

Source-available · BUSL-1.1

Read more about NATS

Wide-column

Durable Execution on ScyllaDB

ScyllaDB · CQL

An implementation on ScyllaDB, one row per promise across many small partitions. It speaks the same HTTP/JSON protocol as the core server, so existing SDKs work unchanged.

Source-available · BUSL-1.1

Read more about ScyllaDB

In-database

Durable Execution on Postgres

Postgres · pg_cron

An implementation with no server process at all — one SQL file, and Postgres becomes storage, queue, and timer. Where the core server uses Postgres, this one is Postgres.

Apache 2.0

Read more about Postgres

Bring your own provider.

The protocol is the enabling asset — implement it against your platform, or tell us what you run and we’ll help you get there. That’s the whole point of durable execution being a protocol.