Postgres transactions are a distributed systems superpower

Techies are having a full-on family dinner argument over one bold claim: maybe your app and its step-by-step workflow should live in the same Postgres database. The article’s pitch is simple enough for non-experts: if the app’s data and the workflow’s progress are saved together, then they can succeed or fail together. In theory, that means fewer weird glitches, fewer double-payments, and less duct-tape bookkeeping. Sounds neat! But the comment section on the post was not ready to clap politely.

The loudest reaction? A giant “hang on a second” from readers who think this is less a breakthrough and more a rebrand. One commenter deadpanned, “Congratulations, you discovered a mutex,” basically accusing the post of dressing up an old idea in shiny distributed-systems cosplay. Another big debate was whether this is really solving a hard problem or just reinventing a queue with better PR. If you write down “send this later” in your database, critics asked, is that truly different from tossing a job into a queue and calling it a day?

Then came the architectural pearl-clutching. Some readers loved the practicality — especially smaller teams saying, “Yep, we already do this, and it works.” Others warned that tying your whole process so tightly to one database could become tomorrow’s breakup nightmare. The vibe was half “this is genius”, half “this is just central database propaganda,” with a side of nerdy stand-up comedy.