pg_durable: Microsoft open sources in-database durable execution

2026 is the year of the Postgres queue! (DBOS[0], pgQue[1]) It's awesome that the community is contributing this and giving us the option to use it.

As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :)

[0]: https://www.dbos.dev/

[1]: https://github.com/NikolayS/pgque

A few things are not clear to me from reading through docs and examples:

    df.wait_for_schedule()

How does this call work? Is it idempotent if I call it from an application? If I run it 2x with the same parameters, does it double tick? Am I invoking this manually from a query console to only do this one time? Am I running this as part of a migration script?

For this[0]:

    -- Wait for human signal (5 minute timeout)
    ~> (df.wait_for_signal('approval', 300) |=> 'sig')

    ~> df.if(
        $$SELECT NOT ($sig::jsonb->>'timed_out')::boolean
            AND ($sig::jsonb->'data'->>'approved')::boolean$$,

Is the `timed_out` a fixed constant that is returned on timeout?

Also not immediately clear: how to handle errors/exceptions?

[0] https://github.com/microsoft/pg_durable/blob/main/examples/i...

If understanding correctly, Absurd (by the Pi LLM harness devs) minimizes the pure db approach as much as possible. I only just started getting into the topic myself, though.

https://github.com/earendil-works/absurd

> When not to use it > … > The workflow mostly lives outside Postgres and spans many heterogeneous systems.

How is this project at all comparable to something like Temporal? Am I misunderstanding the limitation implied by this particular recommendation?

I'm trapped on Azure at work and we're constantly waiting for Azure pg to catch up with modernity.

For example, you cant use this: https://www.paradedb.com/blog/hybrid-search-in-postgresql-th...

Also for example, you dont get ultra-wide high dimensionality vectors.

It is nice they are open sourcing pg_durable, but how about adopting table stakes I'd get with AWS?

This feels like the wrong solution to an age old problem solved by the DAG schedulers like Apache Airflow for a while now.

Why would I want to store my control flow in the database and not in code? It feels strange.

Not trying to dismiss the project, I'm just not getting it yet I think.

Isn't the database already one of the hardest piece of infras to scale? Why would you want to load it with additional long-running jobs?

Can anyone explain why I would want to use this over an orchestration tool that lives outside the DB? Read through the Readme and some of the examples, I still don't get it.

I hope it could be used in the future to export pg_dump formated exports to s3.

One would be able to trigger maintenance jobs via simple lambda functions whose duration is capped.

Is this an open sourcing of something they use internally? My first thought on durable jobs was GHA aka Azure Devops.

Seems like an interesting idea to add durability and resumability to lengthy cron jobs.

Looks pretty good but I wonder why they didn’t build it on pgmq? If you’re on elixir I maintain a DAG package around this (based on and compatible with pgflow.dev which is TS/Deno).

https://github.com/agoodway/pgflow

2026 is the year of the Postgres queue! (DBOS[0], pgQue[1]) It's awesome that the community is contributing this and giving us the option to use it.

As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :)

[0]: https://www.dbos.dev/

[1]: https://github.com/NikolayS/pgque

Yeah, it's harder to work on, or maybe just different, but I guess the docs, info(searchable docs, posts, experience), and tooling are lacking.

What's the story for version control, debugging, testing, releasing? It'd be cool to have everything together for data locality and simplifying the stack, but it feels you'd lose a lot of useful knowledge about how to do stuff "properly".

+1 on "prefer my queue logic to be in code". The <shape> of my data doesn't change nearly as much as the actions I need to take on it; it doesn't make sense to me why I'd want to do a migration (which is an all or nothing op btw) every time I want to change how I behave with my data. This is also why I absolutely abhorred having to make postgres functions to do anything remotely non-trivial on Supabase.

That said, we did hand-build a simple job queue (just lock, poll, reserve on a column, poll and update reservation to mark job done) on top of postgres at my previous startup. Something like pgque would have made that much more polished.

> As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :)

I mean, we used to keep our SQL code in git too for projects where we had DB triggers. I think some were even shoved in there via Django migrations just to let someone setup locally and have the triggers available in their local database.

same but this could be useful for db level things that are not business logic related.

i have always had maintenance packages for this type of stuff. if i could deploy them alongside the database itself that could be kind of cool.

but yeah i agree with you that i do prefer having this in the code layer.

Yeah, it's harder to work on, or maybe just different, but I guess the docs, info(searchable docs, posts, experience), and tooling are lacking.

Contributor here. Good points, we do need to develop some best practices around managing function versioning and lifecycle for pg_durable.

https://github.com/microsoft/duroxide - also OSS, the durable execution framework pg_durable is built on itself supports function versions. We can leverage that to get similar support in pg_durable.

I hope it could be used in the future to export pg_dump formated exports to s3.

One would be able to trigger maintenance jobs via simple lambda functions whose duration is capped.

Committer here. I would love to hear more about this scenario.

Is the proposal to be able to export pg_dump formatted data on some schedule or trigger, entirely hosted in PostgreSQL and with timeouts? There are already extension that can export to blob/file storage and can be combined with pg_durable or pg_cron, so I assume the challenge is pg_dump compatible data export from SQL running in the database?

I'm trapped on Azure at work and we're constantly waiting for Azure pg to catch up with modernity.

For example, you cant use this: https://www.paradedb.com/blog/hybrid-search-in-postgresql-th...

Also for example, you dont get ultra-wide high dimensionality vectors.

It is nice they are open sourcing pg_durable, but how about adopting table stakes I'd get with AWS?

This feels like the wrong solution to an age old problem solved by the DAG schedulers like Apache Airflow for a while now.

Why would I want to store my control flow in the database and not in code? It feels strange.

Not trying to dismiss the project, I'm just not getting it yet I think.

A few things are not clear to me from reading through docs and examples:

    df.wait_for_schedule()

For this[0]:

    -- Wait for human signal (5 minute timeout)
    ~> (df.wait_for_signal('approval', 300) |=> 'sig')

    ~> df.if(
        $$SELECT NOT ($sig::jsonb->>'timed_out')::boolean
            AND ($sig::jsonb->'data'->>'approved')::boolean$$,

Is the `timed_out` a fixed constant that is returned on timeout?

Also not immediately clear: how to handle errors/exceptions?

[0] https://github.com/microsoft/pg_durable/blob/main/examples/i...

If understanding correctly, Absurd (by the Pi LLM harness devs) minimizes the pure db approach as much as possible. I only just started getting into the topic myself, though.

https://github.com/earendil-works/absurd

Contributor here. Good points, we do need to develop some best practices around managing function versioning and lifecycle for pg_durable.

https://github.com/microsoft/duroxide - also OSS, the durable execution framework pg_durable is built on itself supports function versions. We can leverage that to get similar support in pg_durable.

Seems like an interesting idea to add durability and resumability to lengthy cron jobs.

> As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :)

Wouldn't Azure Cosmos DB be better suited for vector searches?

I'm sorry, I'm sure you've considered this, but why couldn't you create a bare VM with Postgres vCurrent installed?

Microsoft has their own Durable Task framewor[1] for that kind of stuff, and it supports both running as a self-hosted standalone service like temporal, and running serverless on Azure Functions. It actually predated airflow, temporal, etc., IIRC.

This one seems to be more database-specific use case. The advantage is probably that you can track the exact state of the job in the database itself, rather than having to cross-reference the workflow log with the codebase and trace through it line by line to figure out what the state is. Plus I assume it's less overhead and latency, and operationally one less thing to spin up.

[1] https://learn.microsoft.com/en-us/azure/durable-task/common/...

Isn't the database already one of the hardest piece of infras to scale? Why would you want to load it with additional long-running jobs?

Long-running jobs on Postgres are not new at all. See pg_cron for one example. At the end of the day, these workloads would be running anyway against the database, whether triggered by an external component. HTTP queries from the database have also become more popular to avoid round-trips and failure points from additional components in data or AI pipelines. But yes, whether to bring the compute to the data or vice-versa is a design choice that has a lot of contention.

Gotta set up the fall to rake in the dough later with consulting fees

Looks pretty good but I wonder why they didn’t build it on pgmq? If you’re on elixir I maintain a DAG package around this (based on and compatible with pgflow.dev which is TS/Deno).

https://github.com/agoodway/pgflow

(pg_durable committer here)

The provider is an extensibility point. We just shipped the simplest version of it. Happy to take contribs if someone sends a pgmq based provider!

> When not to use it > … > The workflow mostly lives outside Postgres and spans many heterogeneous systems.

How is this project at all comparable to something like Temporal? Am I misunderstanding the limitation implied by this particular recommendation?

I aggree - I'm not understanding the value of the project either if you look at the example here https://github.com/microsoft/pg_durable/blob/main/examples/i...

It's an interesting technical achievement I guess, but it's very bizarre to try and read this

    SELECT df.start(
        @> (
            ($$SELECT ... FROM demo.invoices WHERE status = 'pending'$$ |=> 'inv')
            ~> df.if_rows('inv',
                $$UPDATE ... SET status = 'processing'$$
                ~> (df.http(...) |=> 'resp')
                ~> df.if($$SELECT $r.ok$$,
                    -- classify, branch, wait for signal ...
                ),
                df.sleep(5)
            )
        ),
        'invoice-approval-pipeline'
    );

Can anyone explain why I would want to use this over an orchestration tool that lives outside the DB? Read through the Readme and some of the examples, I still don't get it.

Snapshot PITR of your database means everything restores including the durable jobs at the PIT.

Don't need to synchronize the backups with anything else that is part of the same data store, good for ETL pipelines and other state machine type jobs.

If your ETL is mostly SQL anyway, then having the actual job being run on the same server helps as well.

Contributor here. At Microsoft, our Postgres customers seem to split pretty evenly into 2 camps, those that want to do as much as they can in the database, and those that agree with your take - want to keep apps and compute outside the DB.

It’s sometimes convenient if database is the only ”stateful” component in architecture.

Also if all the "state" is in one database, then you have better chance of getting consistent backups.

You can have well-integrated applicative workflows (eg: progress report on a permalink in your front end app), app-restart-proof resumable workflows, and it avoids adding an extra piece of infrastructure.

We use Postgres for that on https://transport.data.gouv.fr (Elixir app which does a fair bit of processing), and it helps.

Not familiar yet with pg_durable though, but I have used or implemented similar solutions and can relate.