source_raw_snapshot
{
"id": "e6eb65bd-8c4d-4b87-9324-8eda8602d9f0",
"daily_ranking_item_id": "d26e87e1-51a0-49fd-85bc-764429370433",
"source": "hacker_news",
"external_id": "48313530",
"fetched_at": "2026-05-28T22:01:23.716Z",
"story_raw": {
"by": "KraftyOne",
"id": 48313530,
"url": "https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution",
"kids": [
48316104,
48314331,
48314295,
48315943,
48314591,
48314969,
48313750,
48314100,
48315400,
48313781,
48313666,
48315843,
48313760,
48313909,
48314940,
48313916,
48314483,
48314218,
48313669,
48315702,
48314163,
48313917,
48314939,
48314282,
48314375,
48313828,
48313997
],
"time": 1779993706,
"type": "story",
"score": 194,
"title": "Just Use Postgres for Durable Workflows",
"descendants": 74
},
"stats_raw": {
"time": 1779993706,
"score": 194,
"descendants": 74
},
"aux_raw": {
"external_url": "https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution",
"hn_comment_url": "https://news.ycombinator.com/item?id=48313530",
"normalized_text": null,
"external_article": {
"title": "Postgres-backed Durable Workflow Execution | DBOS",
"excerpt": "Durable workflows are a simple but powerful tool for building reliable programs. The idea is that as your program runs, you regularly checkpoint its progress to a database. That way, if your program ever crashes or fails, you can reload from the last checkpoint to recover it from its last completed step. You can think of this like saving in a video game: you regularly “save” your program’s progress so that if it crashes, you can “reload” it from its last checkpoint.\n\nMost commonly, durable workflows are implemented via external orchestration . This is the pattern used by systems like Temporal, Airflow, and AWS Step Functions. In this model, durable programs are written as workflows of steps whose execution is coordinated by a central orchestrator.\n\nWhen a client submits a workflow, the orchestrator creates a record for it in a data store then dispatches it to a worker for execution. Each time a worker completes a step, it sends the step’s outcome back to the orchestrator. The orchestrator checkpoints the output in its data store, then dispatches the next step. If a worker crashes or fails, the orchestrator dispatches its workflows to another worker, starting them from their last ch",
"final_url": "https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution",
"fetched_at": "2026-05-28T22:01:17.477Z",
"description": "Explaining the concept of a Postgres-backed durable execution system like DBOS and comparing it to external workflow orchestration systems like Temporal."
},
"selected_comments": [
{
"id": 48316104,
"raw": {
"by": "nzoschke",
"id": 48316104,
"text": "I do love Postgres and DBOS.<p>Recently started experimenting with <a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a> which is also Postgres and even simpler than DBOS. Their comparison is a great read:<p><a href=\"https://earendil-works.github.io/absurd/comparison/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/comparison/</a><p>But for operational reasons I've started using sqlite for durable workflows instead. Porting the database concepts from either DBOS or absurd PG to SQLite is remarkably easy these days. A small polling loop instead of notify/listen feels fine for smaller workloads.",
"time": 1780005571,
"type": "comment",
"parent": 48313530
},
"body": "I do love Postgres and DBOS. Recently started experimenting with https://github.com/earendil-works/absurd which is also Postgres and even simpler than DBOS. Their comparison is a great read: https://earendil-works.github.io/absurd/comparison/ But for operational reasons I've started using sqlite for durable workflows instead. Porting the database concepts from either DBOS or absurd PG to SQLite is remarkably easy these days. A small polling loop instead of notify/listen feels fine for smaller workloads.",
"is_op": false,
"author": "nzoschke",
"raw_body": "I do love Postgres and DBOS.<p>Recently started experimenting with <a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a> which is also Postgres and even simpler than DBOS. Their comparison is a great read:<p><a href=\"https://earendil-works.github.io/absurd/comparison/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/comparison/</a><p>But for operational reasons I've started using sqlite for durable workflows instead. Porting the database concepts from either DBOS or absurd PG to SQLite is remarkably easy these days. A small polling loop instead of notify/listen feels fine for smaller workloads.",
"created_at": 1780005571,
"reply_count": 0
},
{
"id": 48314331,
"raw": {
"by": "buremba",
"id": 48314331,
"kids": [
48314996,
48315640,
48315691,
48314392,
48315660,
48314435,
48314422
],
"text": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for <a href=\"https://lobu.ai\" rel=\"nofollow\">https://lobu.ai</a><p>The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.",
"time": 1779997189,
"type": "comment",
"parent": 48313530
},
"body": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for https://lobu.ai The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.",
"is_op": false,
"author": "buremba",
"raw_body": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for <a href=\"https://lobu.ai\" rel=\"nofollow\">https://lobu.ai</a><p>The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.",
"created_at": 1779997189,
"reply_count": 7
},
{
"id": 48314295,
"raw": {
"by": "llimllib",
"id": 48314295,
"kids": [
48314984
],
"text": "Armin Ronacher's `absurd` is an implementation of durable workflows for postgres:<p><a href=\"https://lucumr.pocoo.org/2025/11/3/absurd-workflows/\" rel=\"nofollow\">https://lucumr.pocoo.org/2025/11/3/absurd-workflows/</a><p><a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a><p><a href=\"https://earendil-works.github.io/absurd/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/</a><p>I've not used it, but it's worth comparing to other options",
"time": 1779996992,
"type": "comment",
"parent": 48313530
},
"body": "Armin Ronacher's `absurd` is an implementation of durable workflows for postgres: https://lucumr.pocoo.org/2025/11/3/absurd-workflows/ https://github.com/earendil-works/absurd https://earendil-works.github.io/absurd/ I've not used it, but it's worth comparing to other options",
"is_op": false,
"author": "llimllib",
"raw_body": "Armin Ronacher's `absurd` is an implementation of durable workflows for postgres:<p><a href=\"https://lucumr.pocoo.org/2025/11/3/absurd-workflows/\" rel=\"nofollow\">https://lucumr.pocoo.org/2025/11/3/absurd-workflows/</a><p><a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a><p><a href=\"https://earendil-works.github.io/absurd/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/</a><p>I've not used it, but it's worth comparing to other options",
"created_at": 1779996992,
"reply_count": 1
},
{
"id": 48315943,
"raw": {
"by": "jgraettinger1",
"id": 48315943,
"text": "At Estuary, we have an in-house Rust crate [1] for building scale-out durable actors / FSMs in Postgres. It powers all async activity in our control plane -- slews of fine-grain scheduled actions, complex change propagation through data-flow topologies, reliable alert and email delivery, and more -- at hundreds to thousands of state transitions per second (today). It's been a wonderful pattern to build on, and is all of three source files.<p>Here's a an example computing a Fibonacci sequence (very inefficiently, with lots of spawned sub-tasks and message passing) [2]<p>[1] <a href=\"https://github.com/estuary/flow/tree/master/crates/automations\" rel=\"nofollow\">https://github.com/estuary/flow/tree/master/crates/automatio...</a>\n[2] <a href=\"https://github.com/estuary/flow/blob/master/crates/automations/tests/fibonacci.rs\" rel=\"nofollow\">https://github.com/estuary/flow/blob/master/crates/automatio...</a>",
"time": 1780004644,
"type": "comment",
"parent": 48313530
},
"body": "At Estuary, we have an in-house Rust crate [1] for building scale-out durable actors / FSMs in Postgres. It powers all async activity in our control plane -- slews of fine-grain scheduled actions, complex change propagation through data-flow topologies, reliable alert and email delivery, and more -- at hundreds to thousands of state transitions per second (today). It's been a wonderful pattern to build on, and is all of three source files. Here's a an example computing a Fibonacci sequence (very inefficiently, with lots of spawned sub-tasks and message passing) [2] [1] https://github.com/estuary/flow/tree/master/crates/automatio... [2] https://github.com/estuary/flow/blob/master/crates/automatio...",
"is_op": false,
"author": "jgraettinger1",
"raw_body": "At Estuary, we have an in-house Rust crate [1] for building scale-out durable actors / FSMs in Postgres. It powers all async activity in our control plane -- slews of fine-grain scheduled actions, complex change propagation through data-flow topologies, reliable alert and email delivery, and more -- at hundreds to thousands of state transitions per second (today). It's been a wonderful pattern to build on, and is all of three source files.<p>Here's a an example computing a Fibonacci sequence (very inefficiently, with lots of spawned sub-tasks and message passing) [2]<p>[1] <a href=\"https://github.com/estuary/flow/tree/master/crates/automations\" rel=\"nofollow\">https://github.com/estuary/flow/tree/master/crates/automatio...</a>\n[2] <a href=\"https://github.com/estuary/flow/blob/master/crates/automations/tests/fibonacci.rs\" rel=\"nofollow\">https://github.com/estuary/flow/blob/master/crates/automatio...</a>",
"created_at": 1780004644,
"reply_count": 0
},
{
"id": 48314591,
"raw": {
"by": "stuartaxelowen",
"id": 48314591,
"kids": [
48315306
],
"text": "My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.",
"time": 1779998462,
"type": "comment",
"parent": 48313530
},
"body": "My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.",
"is_op": false,
"author": "stuartaxelowen",
"raw_body": "My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.",
"created_at": 1779998462,
"reply_count": 1
}
],
"presentation_fields": {
"title": "Just Use Postgres for Durable Workflows",
"tagline": "www.dbos.dev",
"website_url": "https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution",
"canonical_url": "https://news.ycombinator.com/item?id=48313530"
},
"external_url_hostname": "www.dbos.dev",
"selected_comments_raw": [
{
"by": "nzoschke",
"id": 48316104,
"text": "I do love Postgres and DBOS.<p>Recently started experimenting with <a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a> which is also Postgres and even simpler than DBOS. Their comparison is a great read:<p><a href=\"https://earendil-works.github.io/absurd/comparison/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/comparison/</a><p>But for operational reasons I've started using sqlite for durable workflows instead. Porting the database concepts from either DBOS or absurd PG to SQLite is remarkably easy these days. A small polling loop instead of notify/listen feels fine for smaller workloads.",
"time": 1780005571,
"type": "comment",
"parent": 48313530
},
{
"by": "buremba",
"id": 48314331,
"kids": [
48314996,
48315640,
48315691,
48314392,
48315660,
48314435,
48314422
],
"text": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for <a href=\"https://lobu.ai\" rel=\"nofollow\">https://lobu.ai</a><p>The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.",
"time": 1779997189,
"type": "comment",
"parent": 48313530
},
{
"by": "llimllib",
"id": 48314295,
"kids": [
48314984
],
"text": "Armin Ronacher's `absurd` is an implementation of durable workflows for postgres:<p><a href=\"https://lucumr.pocoo.org/2025/11/3/absurd-workflows/\" rel=\"nofollow\">https://lucumr.pocoo.org/2025/11/3/absurd-workflows/</a><p><a href=\"https://github.com/earendil-works/absurd\" rel=\"nofollow\">https://github.com/earendil-works/absurd</a><p><a href=\"https://earendil-works.github.io/absurd/\" rel=\"nofollow\">https://earendil-works.github.io/absurd/</a><p>I've not used it, but it's worth comparing to other options",
"time": 1779996992,
"type": "comment",
"parent": 48313530
},
{
"by": "jgraettinger1",
"id": 48315943,
"text": "At Estuary, we have an in-house Rust crate [1] for building scale-out durable actors / FSMs in Postgres. It powers all async activity in our control plane -- slews of fine-grain scheduled actions, complex change propagation through data-flow topologies, reliable alert and email delivery, and more -- at hundreds to thousands of state transitions per second (today). It's been a wonderful pattern to build on, and is all of three source files.<p>Here's a an example computing a Fibonacci sequence (very inefficiently, with lots of spawned sub-tasks and message passing) [2]<p>[1] <a href=\"https://github.com/estuary/flow/tree/master/crates/automations\" rel=\"nofollow\">https://github.com/estuary/flow/tree/master/crates/automatio...</a>\n[2] <a href=\"https://github.com/estuary/flow/blob/master/crates/automations/tests/fibonacci.rs\" rel=\"nofollow\">https://github.com/estuary/flow/blob/master/crates/automatio...</a>",
"time": 1780004644,
"type": "comment",
"parent": 48313530
},
{
"by": "stuartaxelowen",
"id": 48314591,
"kids": [
48315306
],
"text": "My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can automatically expose to clients in informative ways (this user can like this post, but not edit). It looks colored Petri net shaped to me, but I don’t yet see a simple app state paradigm in the same way that the database has obvious successful boundaries.",
"time": 1779998462,
"type": "comment",
"parent": 48313530
}
]
},
"selection_meta": {
"discussion_depth": "top_comments_v1",
"external_article": {
"status": "ok",
"final_url": "https://www.dbos.dev/blog/postgres-is-all-you-need-for-durable-execution",
"status_code": 200,
"content_type": "text/html; charset=utf-8",
"failure_reason": null
},
"snapshot_version": "hn_story_v3",
"selected_comments_count": 5,
"external_article_resolved": true,
"text_normalization_applied": false
},
"created_at": "2026-05-28T22:01:23.830Z",
"updated_at": "2026-05-28T22:01:23.830Z"
}