by whoiskatrin on 3/27/25, 1:51 PM with 26 comments
by dang on 3/28/25, 8:42 PM
by jedberg on 3/29/25, 1:50 AM
I really enjoyed this blog post. The depth of the technical explanations is appreciated. It really helps me understand the choices you’ve made and why.
We’ve obviously made some different design choices, but each solution has its place.
by randomcatuser on 3/29/25, 5:28 PM
For someone (me) who is new to distributed systems, and what durable execution even is, I learned a lot (both from the blog post & the examples!). thanks!
ChatGPT also helped :)
by oulipo on 3/27/25, 6:03 PM
by agentultra on 3/29/25, 4:06 AM
by solatic on 3/29/25, 7:56 AM
One of the good reasons why most products will layer on top of an established database like Postgres is because concerns like ACID are solved problems in those databases, and the database itself is well battle-hardened, Jepsen-tested with a reputation for reliability, etc. One of the reasons why many new database startups fail is precisely because it is so difficult to get over that hump with potential customers - you can't really improve reliability until you run into production bugs, and you can't sell because it's not reliable. It's a tough chicken-and-egg problem.
I appreciate you have reasons to build your own persistence layer here (like a push-based model), but doesn't doing so expose you to the same kind of risk as a new database startup? Particularly when we're talking about a database for durable execution, for which, you know, durability is a hard requirement?
by xwowsersx on 3/29/25, 12:53 AM