Postgres as the backbone of distributed systems
A piece on 'Postgres transactions as a distributed systems superpower' sparked a pointed debate. One commenter dismissed it immediately: 'Congratulations, you discovered a mutex. Is it really a distributed system or just a bunch of services with a central database?' But others pushed back, arguing that using Postgres as a state store for distributed workflows is a legitimate and underrated architectural pattern.
The debate touches something real. A lot of 'distributed systems' in the wild are actually multiple services sharing one Postgres instance, and pretending otherwise adds complexity without benefit. The thread circles around whether that's a crutch or just honest engineering.
Meanwhile, the 14x embedding speed improvement in Manticore by rebuilding the ONNX path shows that the Postgres-adjacent data infrastructure space is still getting meaningful performance gains from low-level optimization, not just scaling out.
So what?
Before you reach for Kafka, a distributed lock service, or a saga pattern, ask whether Postgres transactions already solve your consistency problem. The friction in that HN thread suggests a lot of engineers are over-architecting problems that a well-used Postgres instance handles fine. Simpler is faster to ship and cheaper to run.