A Python job can sleep in Postgres and wake where it stopped
Waymark compiles supported Python workflows into a durable virtual machine. Its pre-1.0 warning matters as much as its clever recovery mechanism.
A job that spends three days waiting for something should not require three days of keeping your fingers crossed. Computers can make surprisingly demanding houseplants.
Waymark’s repository takes an unusual route through that problem. You write an async Python workflow. Its compiler turns the workflow’s control flow into an intermediate representation and then bytecode for a Rust virtual machine. The VM can persist its state in Postgres, leaving a record of where execution should continue.
That gives “save your work” a fairly literal meaning. The workflow’s place in the program becomes something the engine can store. After an interruption, it resumes from the stored execution state, rather than recovering its position by replaying the Python workflow definition.
The distinction matters when a workflow contains long waits and several stages. A process may need to pause for an approval, wake up, launch several activities together, and collect their results. In Waymark’s model, supported uses of familiar operations such as asyncio.sleep and asyncio.gather fit into durable execution. The waiting room can survive the receptionist’s computer restarting.
Postgres is also the infrastructure requirement worth noticing. The project describes an engine that needs no additional infrastructure beyond that database. For someone already maintaining Postgres, trying a durable job does not immediately mean adopting a separate queue service and several supporting systems. It still means running and understanding this engine, of course. A shorter shopping list does not maintain itself.
The repository is unusually direct about who should hold off. It says not to use Waymark in production before 1.0. That warning belongs beside the interesting mechanism, rather than buried below an imaginary deployment success story. A compiled workflow engine needs clear answers about its supported language features and recovery behavior before it starts carrying business obligations.
The authors also identify workloads outside its intended fit: latency-sensitive work below 100 milliseconds and workflows coordinating more than 10,000 simultaneous actions. Those are the project’s stated boundaries, not measurements from a LockerGnome benchmark. If either describes your job, the clever storage mechanism does not erase the mismatch.
The sensible first experiment is something with a visible wait and a result you can inspect afterward. Keep its external actions harmless. Verify the behavior you need before assigning it an email, payment or irreversible operation; this description of stored workflow state does not establish exactly-once behavior for every outside service.
There is an appealing idea here even for readers who never install it: a program’s place can be data. Saving that place in an ordinary database gives a sleeping job somewhere concrete to spend the night.
Postgres has acquired another lodger.