May 28, 2026

Postgres: hero or chaos goblin?

Just Use Postgres for Durable Workflows

Why add another bossy tool when your database is already doing the job

TLDR: The article argues you can skip a separate workflow manager and use Postgres itself to save progress and recover after crashes. Commenters were wildly divided: some praised the simplicity, while others warned it’s just reinventing existing tools — with one reader joking a database comparison made them “spit out coffee.”

A spicy new blog post basically says: stop hiring extra middlemen for reliable app workflows and just let Postgres — a very popular database — keep track of what’s finished, what crashed, and what needs to resume. The pitch is simple enough for non-engineers: instead of a separate “traffic cop” service telling every step what to do, your app can save progress directly in the database and pick back up after a failure, like reloading a game save. For teams worried about wasted AI costs or duplicate orders, that’s a big deal.

But the real show was in the comments, where the crowd split into Team Postgres Can Do Anything and Team Congrats, You Reinvented a Worse Wheel. One fan practically swooned over how much can be built with “few tools” as long as Postgres is in the toolbox, bragging about a queue that benchmarks well and avoids workers stepping on each other. On the other side, skeptics rolled their eyes at the classic developer habit of building a homemade version of an existing product, then discovering why the boring, supported option exists. One commenter flat-out asked where clever engineering ends and NIH — “not invented here” syndrome — begins.

Then came the comedy. The biggest laugh landed when a reader saw CockroachDB mentioned as an example of “scaling Postgres” and said it made them “spit out coffee”, immediately wondering if the piece was AI-written. That one line basically became the thread’s reaction meme. Meanwhile, another user gave Temporal some respect for enforcing good habits, while still grumbling that real-life annoyances — like a CSV file over 2MB — can turn elegant systems into paperwork. In other words: everyone loves simplicity, until they’re the one debugging it.

Key Points

  • The article defines durable execution as checkpointing program state to a database so workflows can resume from the last completed step after failure.
  • The common implementation pattern described is external orchestration, where systems such as Temporal, Apache Airflow, and AWS Step Functions manage workflow dispatch and checkpointing.
  • The article argues that a separate orchestrator is unnecessary and that Postgres can act as the coordination layer for durable workflows.
  • In the proposed design, clients write workflow records to Postgres, application servers poll and dequeue them, and workers checkpoint each step directly into the database.
  • The article states that scalability and availability in a database-backed durable execution system depend primarily on the underlying database, while horizontal scale comes from adding worker servers.

Hottest takes

"made me spit out coffee. Was this LLM-written?" — senderista
"you tend to home-grow an ad-hoc version of many of the existing OSS tools" — switchbak
"works really good... my only problem... some limits on request payload or event sizes" — throwaw12
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.