4 ms·

well if my system spwans new database connection in an open transaction, than you have more problems than just your database. they even had another talk where t

by merb 10y ago

well if my system spwans new database connection in an open transaction, than you have more problems than just your database. they even had another talk where they let their master die, but just ignoring "free space left on device" messages. Well even Skype could've handled PostgreSQL and they probably had a smaller pool of engineers.

foldr 10y ago
I'm not a big fan of Uber as a company and I don't necessarily think that their engineering team is the shit (I really don't know). But my heuristic here is "any problem that Uber engineers aren't smart enough to avoid is a problem that I might very well face myself".
- merb 10y ago
  well I think a lot of problems arise in these fast running companies. a company that scale's up slowly and brings their tech stack up and forward with a small team that slowly adds people (so that everybody can learn from people working a little bit longer on the stack) will lead to a way more sane teck stack than a extremly fast growing team + technology. also I loved some talks about instagram. (https://de.slideshare.net/iammutex/scaling-instagram https://de.slideshare.net/iammutex/scaling-instagram) Scaling: replacing all components of a car while driving it at 100mph (And the end slides 150+ are awesome, too). And while they use PostgreSQL and talk about everything, they also did engineering quite right and prolly that's the problem of Uber. They tried to get to big to fast and know everything burns (not just their tech).
- ldrndll 10y ago
  I'm not so sure that's an appropriate heuristic here. The problems they faced were partly a result of scale[1]. Most companies with scaling problems of the same magnitude as Uber have engineers competent enough to correctly handle the issues they cited as reasons for switching. Honestly, there are hugely people at any number of Postgres consultancies that could have helped them setup logical replication - since they complained about it being difficult to do - which seems like it would have solved many of their issues. I'd like to believe Uber had the resources to do this, if they had cared to. [1] For example, write amplification.

by merb 10y ago

foldr 10y ago

I'm not a big fan of Uber as a company and I don't necessarily think that their engineering team is the shit (I really don't know). But my heuristic here is "any problem that Uber engineers aren't smart enough to avoid is a problem that I might very well face myself".

merb 10y ago
well I think a lot of problems arise in these fast running companies. a company that scale's up slowly and brings their tech stack up and forward with a small team that slowly adds people (so that everybody can learn from people working a little bit longer on the stack) will lead to a way more sane teck stack than a extremly fast growing team + technology. also I loved some talks about instagram. (https://de.slideshare.net/iammutex/scaling-instagram https://de.slideshare.net/iammutex/scaling-instagram) Scaling: replacing all components of a car while driving it at 100mph (And the end slides 150+ are awesome, too). And while they use PostgreSQL and talk about everything, they also did engineering quite right and prolly that's the problem of Uber. They tried to get to big to fast and know everything burns (not just their tech).
ldrndll 10y ago
I'm not so sure that's an appropriate heuristic here. The problems they faced were partly a result of scale[1]. Most companies with scaling problems of the same magnitude as Uber have engineers competent enough to correctly handle the issues they cited as reasons for switching. Honestly, there are hugely people at any number of Postgres consultancies that could have helped them setup logical replication - since they complained about it being difficult to do - which seems like it would have solved many of their issues. I'd like to believe Uber had the resources to do this, if they had cared to. [1] For example, write amplification.