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.
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?
joelthelion
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?
show comments
oa335
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.
show comments
rastignack
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.
mikey_p
Is this an open sourcing of something they use internally? My first thought on durable jobs was GHA aka Azure Devops.
show comments
redmonduser
Seems like an interesting idea to add durability and resumability to lengthy cron jobs.
cpursley
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).
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
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?
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.
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?
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