What Durable Execution Means, in Three Postgres Libraries

What durable execution actually fixes

Lucas Carlson, who lists himself on GitHub as the author of the Ruby Cookbook and former chief executive of AppFog, published two production bugs on Sept. 8 to explain why he spent months building Solid Objects. A cron job meant to scan every account every five minutes was instead turning up only eight results a week, because a crashed run silently dropped its place in line. A scheduled-launch feature parsed timing keys with regular expressions and drifted by 30 minutes under load. Both are the same underlying problem: ordinary application code has no way to guarantee that a multi-step process finishes exactly once, in order, even if the process restarts halfway through. That guarantee is what "durable execution" means, and it's also what Cloudflare sells as Durable Objects, a hosted actor model tied to Cloudflare's own infrastructure.

Carlson's library gives an application an addressable object with its own state and its own single-threaded inbox. Referencing Counter.ref("global") and sending it a message causes exactly one process to win a database lease, run that turn, and commit the resulting state, reminders and outbound effects together. On a single machine using SQLite, Carlson measured that round trip at about 2.6 milliseconds at the 50th percentile; spread across two processes coordinating only through polling, the same operation takes roughly a second. Solid Objects runs on Node 24 or Rails 7.1 and up, against Postgres, MySQL or SQLite, and Carlson says it is already running inside one Rails application with more than 100,000 users. It is pre-1.0, at version 0.14.7, under the MIT license.

Two other teams solved the same problem since November 2025

What Carlson's post does not mention is that Solid Objects is the third database-only durable-execution system to appear in less than a year, each built independently and none citing the others. Microsoft open-sourced pg_durable on June 10, a Postgres extension paired with a background worker that runs workflows as graphs of SQL steps, built on two Rust libraries the company calls duroxide and duroxide-pg. Ten months earlier, on Nov. 3, 2025, Flask creator Armin Ronacher published Absurd, a single SQL file that turns a Postgres table into a task queue using SELECT ... FOR UPDATE SKIP LOCKED, with each workflow step checkpointed so a crash resumes rather than restarts.

All three reject the same thing: standing up Temporal, a message broker or a Cloudflare account just to make a background job resumable. But they disagree on the mechanism. Ronacher's Absurd retries whole tasks, never individual steps, and treats the job queue as the unit of durability. Microsoft's pg_durable pushes the orchestration logic into the database itself, through an extension and a worker process, so an application server does not have to run its own scheduler. Carlson's Solid Objects instead models each unit of state as an addressable actor with a mailbox, closer to Cloudflare's own programming model than to a task queue at all. A team picking between them is really choosing between three different failure models, not three implementations of one idea.

What Solid Objects doesn't cover yet

Carlson's own launch post raises a question he has not settled: whether the workerless, synchronous execution path he chose as the default is right for an ordinary Rails app, or whether requiring a background worker up front would be less likely to surprise a developer who expects one. He also points to Shopify, which he says separately published an identical pattern for inventory reservations, moving them out of Redis and into MySQL, as evidence the design is sound rather than as a citation he built on. Nothing in the release compares Solid Objects' 2.6-millisecond figure against pg_durable's or Absurd's under equivalent load, so a team cannot yet tell which of the three actually costs less at the database layer once real traffic arrives. That's a familiar gap: this outlet found Intel's Crescent Island accelerator pitched itself on a single metric, tokens per watt, while publishing neither that number nor the memory bandwidth needed to judge it. As with Anthropic's Claude Fable 5.1 update, which added a data-retention rule its release notes did not flag as a breaking change, the gap here is disclosure rather than capability: three teams solved a real problem independently, and none of the three has said how their approach fails compared with the other two.