5 ms·
Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested." Clearly a process per connection is more stable and tha
by TZubiri 4mo ago
Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested."
Clearly a process per connection is more stable and that's what I'm using.
It's unclear what problem such optimizations are solving anyway, with the old way you could only support a million concurrent users with a single server? Are we missing out on supporting ten million concurrent users with 2 servers instead of 10? Ostensibly reducing the minimum db hardware opex for a 10B$ company from 10k$/month to 2k$/month?
- film42 4mo agoA million users? Hell, I'd bet 99.999% of live postgres databases in existence serve less than 5 users on average. Even among products that actually make a profit, I bet 99.9% of them serve less than 100 customers a day. We hooligans on hacker news manage the 0.1% of databases, and in my newfound consulting life, I'm hoping to never support one of those again.
- vanviegen 4mo ago> Clearly a process per connection is more stable Even if those processes share most of their memory, and are written in a notoriously memory-unsafe language? A significant performance improvement can well be the difference between being able to run the entire database on one beefy server, and having to shard. And that has a huge cost in terms of complexity and thus reliability and development time.