Postgres transactions are a distributed systems superpower
1–10 of 108 posts
Re: Postgres transactions are a distributed systems superpower
#2Congratulations, you discovered a mutex.
Is it really a distributed system or just a bunch of services with a central database?
Re: Postgres transactions are a distributed systems superpower
#3i don't understand the last point of UDF.
Either you need the state to be updated atomically across different systems or you don't.
But writing a row in a system in order to update the second one at any random time in the future isn't really much different from enqueuing a job in queue.
Re: Postgres transactions are a distributed systems superpower
#4Congratulations, you discovered a mutex. Is it really a distributed system or just a bunch of services with a central database?
[deleted]
Re: Postgres transactions are a distributed systems superpower
#5Congratulations, you discovered a mutex. Is it really a distributed system or just a bunch of services with a central database?
I don't think it's true that distributed and decentralized mean the same thing. A hub and spoke rail system is centralized, but it's still a distributed system, if it has multiple trains running concurrently.* A distributed system has to coordinate somehow, and a single central DB is one way of doing it.
*: edit, maybe a better example here is a rail system with a single central dispatcher is centralized but may still be distributed
Re: Postgres transactions are a distributed systems superpower
#6Can you use postgres as a state store for a distributed application?
It seems this article is trending toward that view: If you can maintain transactional consistency along with application workflow state, then would this generalize to maintaining distributed application state in general?
The follow-up would be: Would this be preferable to Valkey/Redis?
Re: Postgres transactions are a distributed systems superpower
#7Congratulations, you discovered a mutex. Is it really a distributed system or just a bunch of services with a central database?
I don't think it's true that distributed and decentralized mean the same thing. A hub and spoke rail system is centralized, but it's still a distributed system, if it has multiple trains running concurrently.* A distributed system has to coordinate somehow, and a single central DB is one way of doing it. *: edit, maybe a better example here is a rail system with a single central dispatcher is centralized but may stil…
Exactly! It's a distributed system, with many processes performing work in parallel, with a central database as a coordination point, used as little as possible. A mutex wouldn't get quite the same performance :)
Re: Postgres transactions are a distributed systems superpower
#8i don't understand the last point of UDF. Either you need the state to be updated atomically across different systems or you don't. But writing a row in a system in order to update the second one at any random time in the future isn't really much different from enqueuing a job in queue.
The key is that the UDF's enqueue is transactional with the database update. Let's say the database update is inserting a new order. This provides the guarantee that if a new order is inserted, a job to process the order is also enqueued. It's impossible for a new order to be inserted without its processing job also being enqueued. Then the durable workflow/queue system is responsible for making sure the processing job, once enqueued, actually executes.
Re: Postgres transactions are a distributed systems superpower
#9Can you use postgres as a state store for a distributed application? It seems this article is trending toward that view: If you can maintain transactional consistency along with application workflow state, then would this generalize to maintaining distributed application state in general? The follow-up would be: Would this be preferable to Valkey/Redis?
[dead]
Re: Postgres transactions are a distributed systems superpower
#10Congratulations, you discovered a mutex. Is it really a distributed system or just a bunch of services with a central database?
I don't think it's true that distributed and decentralized mean the same thing. A hub and spoke rail system is centralized, but it's still a distributed system, if it has multiple trains running concurrently.* A distributed system has to coordinate somehow, and a single central DB is one way of doing it. *: edit, maybe a better example here is a rail system with a single central dispatcher is centralized but may stil…
In fact - if you're building a very large distributed system the goal is usually to shrink that centralized component to the smallest and most robust surface you can. If the system is well designed it is amazing just how much consistency power you can get from a tiny component of centralization.
There are always tradeoffs of course, but building a truly decentralized system requires some really difficult compromises to correctness. The two general's problem is a great piece of reading on this topic - distribution always requires compromises in general, but to fully remove an authority on truth gets quite tricky.