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.

▲

daxfohl an hour ago | parent [-]

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/...

▲

affandar 40 minutes ago | parent [-]

(Author of both durable task framework and pg_durable/duroxide here)

Indeed Durable tasks is an exceptional project and was a unique innovation at the time.

pg_durable brings the same reliability and durablity semantics to long running operations within the database.

We have tons of interesting scenarios on the roadmap. Stay tuned! :)

	▲	alex_hirner 6 minutes ago \| parent [-]
		Does ai.backfill() fill incomplete/dirty rows or does pg_durable have some notion of partial completion?