obeli.sk
痛点为 AI 基于上游原始证据的初步提炼；未包含额外中国市场检索。
在构建需要持久化状态的工作流系统时，开发者面临一个核心矛盾：既要保证工作流状态在进程崩溃后不丢失，又不想引入额外的数据库服务（如Postgres）带来的运维负担。现有方案中，使用Postgres等独立数据库需要管理网络连接、控制平面和额外的操作面，增加了复杂性和成本；而使用文件系统存储状态则缺乏事务保证和结构化查询能力。这种摩擦导致开发者不得不在可靠性和简洁性之间妥协，要么接受更重的基础设施，要么忍受状态丢失或数据不一致的风险。评论中有人提到使用Temporal等编排工具虽然可靠，但依然依赖外部服务；而SQLite作为嵌入式数据库，虽然能提供事务性持久化，但并发能力弱，不适合多进程场景，这又引发了新的权衡。
DBOS recently argued that Postgres is all you need for durable execution: if you already trust your database, you do not need a separate orchestration tier. I a…
I started using SQLite for a home project after years of reading about it, I was shocked at the poor type system coming from Postgres. It is really inferior, not sure why it gets so much praise. https://sqlite.org/datatype3.html https://www.postgresql.org/docs/current/datatype.html Working with date/time feels like using a 30years old database, nothing is enforced at insert. Really someone needs to explain why so many people like it.
I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with. Additionally, the web UI makes it very easy to inspect workflows, review agent execution, etc. Temporal also encodes much higher reliability into your system, almost for free. Distributed and reliable systems are hard, don't reinvent the wheel IMO. If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look. Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLite for everything" crowd is a little bit inexperienced.
I went from using the various big player postgres clusters to SQLite, we have an MAU in 7 figures, all backed by SQLite durable objects. We have to think differently about the access patterns but the benefits have been worth it.
There's a wide gap from files to multipartition databases. Running databases in a container is not for me sorry whenever real production stuff is on the table. Personally, lots of ETL can just be taken care of locally without involving enterprise databases. In such cases, DuckDB is 5x-10x better than SQLite and orders of magnitude simpler/faster than spinning up a dedicated Postgres database. For general scripting, there's no match between a 20-lines awk script and a much cleaner, robust, maintainable equivalent SQL script based on DuckDB. I just hope MotherDuck don't need to pump/dump for IPO - it would be sad losing that tool for the usual corporate greed.
{
"author": "tomasol",
"hn_item_id": 48326802,
"external_url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/"
}{
"by": "tomasol",
"id": 48326802,
"url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"kids": [
48329530,
48327121,
48327679,
48329730,
48328583,
48327584,
48329476,
48328239,
48329550,
48327872,
48329406,
48329844,
48329144,
48327859,
48327260,
48326956,
48328974,
48328728,
48327763,
48327076,
48327849,
48327995,
48328124,
48328009,
48326924,
48326943,
48329679,
48328415,
48328601,
48328096,
48327797
],
"time": 1780077290,
"type": "story",
"score": 245,
"title": "SQLite is all you need for durable workflows",
"descendants": 126
}{
"id": "02088b94-f9ea-45e9-80d5-6112370c312c",
"daily_ranking_item_id": "a7b977b7-3c71-4a40-9ebc-60694d29c475",
"source": "hacker_news",
"external_id": "48326802",
"fetched_at": "2026-05-29T22:01:20.905Z",
"story_raw": {
"by": "tomasol",
"id": 48326802,
"url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"kids": [
48329530,
48327121,
48327679,
48329730,
48328583,
48327584,
48329476,
48328239,
48329550,
48327872,
48329406,
48329844,
48329144,
48327859,
48327260,
48326956,
48328974,
48328728,
48327763,
48327076,
48327849,
48327995,
48328124,
48328009,
48326924,
48326943,
48329679,
48328415,
48328601,
48328096,
48327797
],
"time": 1780077290,
"type": "story",
"score": 245,
"title": "SQLite is all you need for durable workflows",
"descendants": 126
},
"stats_raw": {
"time": 1780077290,
"score": 245,
"descendants": 126
},
"aux_raw": {
"external_url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"hn_comment_url": "https://news.ycombinator.com/item?id=48326802",
"normalized_text": null,
"external_article": {
"title": "SQLite is All You Need for Durable Workflows - Blog",
"excerpt": "DBOS recently argued that Postgres is all you need for durable execution : if you already trust your database, you do not need a separate orchestration tier. I agree with the direction, and I think the idea can be pushed further.\n\nFor a large class of durable systems, SQLite is all you need.\n\nDurable execution is often discussed as if it requires durable infrastructure. In many cases it does not. The durable part is the workflow state. The compute can stay cheap and disposable.\n\nThat is a natural fit for Obelisk: workflow progress lives in an execution log, workflows replay from persisted history, and activities can be retried. What matters most is keeping the workflow state around and easy to inspect.\n\nSQLite is appealing because it gives you transactional durable state without introducing a separate database service. There is no network hop, no extra control plane, and no new operational surface area just to keep workflow progress safe. For many systems, a local database file is exactly the right level of machinery.\n\nThe obvious concern is what to do with those SQLite files once experiments start to accumulate. That is where Litestream helps. It can stream SQLite changes asynchro",
"final_url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"fetched_at": "2026-05-29T22:01:18.030Z",
"description": "DBOS recently argued that Postgres is all you need for durable execution: if you already trust your database, you do not need a separate orchestration tier. I a…"
},
"selected_comments": [
{
"id": 48329530,
"raw": {
"by": "Thaxll",
"id": 48329530,
"kids": [
48329643,
48329591,
48329608,
48329691,
48329628
],
"text": "I started using SQLite for a home project after years of reading about it, I was shocked at the poor type system coming from Postgres. It is really inferior, not sure why it gets so much praise.<p><a href=\"https://sqlite.org/datatype3.html\" rel=\"nofollow\">https://sqlite.org/datatype3.html</a><p><a href=\"https://www.postgresql.org/docs/current/datatype.html\" rel=\"nofollow\">https://www.postgresql.org/docs/current/datatype.html</a><p>Working with date/time feels like using a 30years old database, nothing is enforced at insert. Really someone needs to explain why so many people like it.",
"time": 1780090109,
"type": "comment",
"parent": 48326802
},
"body": "I started using SQLite for a home project after years of reading about it, I was shocked at the poor type system coming from Postgres. It is really inferior, not sure why it gets so much praise. https://sqlite.org/datatype3.html https://www.postgresql.org/docs/current/datatype.html Working with date/time feels like using a 30years old database, nothing is enforced at insert. Really someone needs to explain why so many people like it.",
"is_op": false,
"author": "Thaxll",
"raw_body": "I started using SQLite for a home project after years of reading about it, I was shocked at the poor type system coming from Postgres. It is really inferior, not sure why it gets so much praise.<p><a href=\"https://sqlite.org/datatype3.html\" rel=\"nofollow\">https://sqlite.org/datatype3.html</a><p><a href=\"https://www.postgresql.org/docs/current/datatype.html\" rel=\"nofollow\">https://www.postgresql.org/docs/current/datatype.html</a><p>Working with date/time feels like using a 30years old database, nothing is enforced at insert. Really someone needs to explain why so many people like it.",
"created_at": 1780090109,
"reply_count": 5
},
{
"id": 48327121,
"raw": {
"by": "bitexploder",
"id": 48327121,
"kids": [
48329309,
48327227,
48328413,
48327922
],
"text": "I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with. Additionally, the web UI makes it very easy to inspect workflows, review agent execution, etc. Temporal also encodes much higher reliability into your system, almost for free. Distributed and reliable systems are hard, don't reinvent the wheel IMO.<p>If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look.<p>Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.",
"time": 1780078632,
"type": "comment",
"parent": 48326802
},
"body": "I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with. Additionally, the web UI makes it very easy to inspect workflows, review agent execution, etc. Temporal also encodes much higher reliability into your system, almost for free. Distributed and reliable systems are hard, don't reinvent the wheel IMO. If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look. Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.",
"is_op": false,
"author": "bitexploder",
"raw_body": "I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with. Additionally, the web UI makes it very easy to inspect workflows, review agent execution, etc. Temporal also encodes much higher reliability into your system, almost for free. Distributed and reliable systems are hard, don't reinvent the wheel IMO.<p>If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look.<p>Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.",
"created_at": 1780078632,
"reply_count": 4
},
{
"id": 48327679,
"raw": {
"by": "levkk",
"id": 48327679,
"kids": [
48328066,
48328417,
48328167,
48328114,
48328067,
48329151,
48328094,
48328016,
48329532,
48327709,
48327823,
48328249,
48327705,
48329089,
48327782,
48328499,
48329191,
48328902,
48327808,
48327992,
48327790
],
"text": "I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time.<p>This is a foundational principle of computer science. It seems to me that the "SQLite for everything" crowd is a little bit inexperienced.",
"time": 1780080877,
"type": "comment",
"parent": 48326802
},
"body": "I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the \"SQLite for everything\" crowd is a little bit inexperienced.",
"is_op": false,
"author": "levkk",
"raw_body": "I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time.<p>This is a foundational principle of computer science. It seems to me that the "SQLite for everything" crowd is a little bit inexperienced.",
"created_at": 1780080877,
"reply_count": 21
},
{
"id": 48329730,
"raw": {
"by": "PUSH_AX",
"id": 48329730,
"text": "I went from using the various big player postgres clusters to SQLite, we have an MAU in 7 figures, all backed by SQLite durable objects. We have to think differently about the access patterns but the benefits have been worth it.",
"time": 1780091085,
"type": "comment",
"parent": 48326802
},
"body": "I went from using the various big player postgres clusters to SQLite, we have an MAU in 7 figures, all backed by SQLite durable objects. We have to think differently about the access patterns but the benefits have been worth it.",
"is_op": false,
"author": "PUSH_AX",
"raw_body": "I went from using the various big player postgres clusters to SQLite, we have an MAU in 7 figures, all backed by SQLite durable objects. We have to think differently about the access patterns but the benefits have been worth it.",
"created_at": 1780091085,
"reply_count": 0
},
{
"id": 48328583,
"raw": {
"by": "m2f2",
"id": 48328583,
"kids": [
48329017
],
"text": "There's a wide gap from files to multipartition databases.\nRunning databases in a container is not for me sorry whenever real production stuff is on the table.<p>Personally, lots of ETL can just be taken care of locally without involving enterprise databases. In such cases, DuckDB is 5x-10x better than SQLite and orders of magnitude simpler/faster than spinning up a dedicated Postgres database.<p>For general scripting, there's no match between a 20-lines awk script and a much cleaner, robust, maintainable equivalent SQL script based on DuckDB.<p>I just hope MotherDuck don't need to pump/dump for IPO - it would be sad losing that tool for the usual corporate greed.",
"time": 1780085614,
"type": "comment",
"parent": 48326802
},
"body": "There's a wide gap from files to multipartition databases. Running databases in a container is not for me sorry whenever real production stuff is on the table. Personally, lots of ETL can just be taken care of locally without involving enterprise databases. In such cases, DuckDB is 5x-10x better than SQLite and orders of magnitude simpler/faster than spinning up a dedicated Postgres database. For general scripting, there's no match between a 20-lines awk script and a much cleaner, robust, maintainable equivalent SQL script based on DuckDB. I just hope MotherDuck don't need to pump/dump for IPO - it would be sad losing that tool for the usual corporate greed.",
"is_op": false,
"author": "m2f2",
"raw_body": "There's a wide gap from files to multipartition databases.\nRunning databases in a container is not for me sorry whenever real production stuff is on the table.<p>Personally, lots of ETL can just be taken care of locally without involving enterprise databases. In such cases, DuckDB is 5x-10x better than SQLite and orders of magnitude simpler/faster than spinning up a dedicated Postgres database.<p>For general scripting, there's no match between a 20-lines awk script and a much cleaner, robust, maintainable equivalent SQL script based on DuckDB.<p>I just hope MotherDuck don't need to pump/dump for IPO - it would be sad losing that tool for the usual corporate greed.",
"created_at": 1780085614,
"reply_count": 1
}
],
"presentation_fields": {
"title": "SQLite is all you need for durable workflows",
"tagline": "obeli.sk",
"website_url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"canonical_url": "https://news.ycombinator.com/item?id=48326802"
},
"external_url_hostname": "obeli.sk",
"selected_comments_raw": [
{
"by": "Thaxll",
"id": 48329530,
"kids": [
48329643,
48329591,
48329608,
48329691,
48329628
],
"text": "I started using SQLite for a home project after years of reading about it, I was shocked at the poor type system coming from Postgres. It is really inferior, not sure why it gets so much praise.<p><a href=\"https://sqlite.org/datatype3.html\" rel=\"nofollow\">https://sqlite.org/datatype3.html</a><p><a href=\"https://www.postgresql.org/docs/current/datatype.html\" rel=\"nofollow\">https://www.postgresql.org/docs/current/datatype.html</a><p>Working with date/time feels like using a 30years old database, nothing is enforced at insert. Really someone needs to explain why so many people like it.",
"time": 1780090109,
"type": "comment",
"parent": 48326802
},
{
"by": "bitexploder",
"id": 48327121,
"kids": [
48329309,
48327227,
48328413,
48327922
],
"text": "I started setting up my workflows using Temporal. It deploys as relatively light weight local app. For an isolated local installation it uses SQLite. It makes the process of dealing with API retries and organizing workflows and tasks really simple. I recommend giving it a try. It is, philosophically, exactly what this article is suggesting, but it adds an incredibly rich and flexible interface for agents to work with. Additionally, the web UI makes it very easy to inspect workflows, review agent execution, etc. Temporal also encodes much higher reliability into your system, almost for free. Distributed and reliable systems are hard, don't reinvent the wheel IMO.<p>If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look.<p>Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.",
"time": 1780078632,
"type": "comment",
"parent": 48326802
},
{
"by": "levkk",
"id": 48327679,
"kids": [
48328066,
48328417,
48328167,
48328114,
48328067,
48329151,
48328094,
48328016,
48329532,
48327709,
48327823,
48328249,
48327705,
48329089,
48327782,
48328499,
48329191,
48328902,
48327808,
48327992,
48327790
],
"text": "I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time.<p>This is a foundational principle of computer science. It seems to me that the "SQLite for everything" crowd is a little bit inexperienced.",
"time": 1780080877,
"type": "comment",
"parent": 48326802
},
{
"by": "PUSH_AX",
"id": 48329730,
"text": "I went from using the various big player postgres clusters to SQLite, we have an MAU in 7 figures, all backed by SQLite durable objects. We have to think differently about the access patterns but the benefits have been worth it.",
"time": 1780091085,
"type": "comment",
"parent": 48326802
},
{
"by": "m2f2",
"id": 48328583,
"kids": [
48329017
],
"text": "There's a wide gap from files to multipartition databases.\nRunning databases in a container is not for me sorry whenever real production stuff is on the table.<p>Personally, lots of ETL can just be taken care of locally without involving enterprise databases. In such cases, DuckDB is 5x-10x better than SQLite and orders of magnitude simpler/faster than spinning up a dedicated Postgres database.<p>For general scripting, there's no match between a 20-lines awk script and a much cleaner, robust, maintainable equivalent SQL script based on DuckDB.<p>I just hope MotherDuck don't need to pump/dump for IPO - it would be sad losing that tool for the usual corporate greed.",
"time": 1780085614,
"type": "comment",
"parent": 48326802
}
]
},
"selection_meta": {
"discussion_depth": "top_comments_v1",
"external_article": {
"status": "ok",
"final_url": "https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/",
"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-29T22:01:20.959Z",
"updated_at": "2026-05-29T22:01:20.959Z"
}