4 ms·

It's not harder to use than MySQL. And for everything (even MySQL) the rule of thumb is: if you are not confident with the technology don't use it or let somebo

by merb 10y ago

It's not harder to use than MySQL. And for everything (even MySQL) the rule of thumb is: if you are not confident with the technology don't use it or let somebody else manage it.

foldr 10y ago
Sure, I wasn't making a claim about how easy to use postgres actually is. My point was that these slides give the impression (I assume inadvertently) that postgres is difficult to use by making fun of Uber engineers' alleged inability to use it correctly.
- 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.
- cookiecaper 10y ago
  My reading was less that PostgreSQL was "too difficult to use" and more that MySQL is less strict about safety. That difference is more substantial than it may sound. "An ounce of prevention is worth a pound of cure", as they say. While PostgreSQL may do things in a way that require a little extra annoyance up front, they're usually that way to prevent disastrous data integrity issues further down the line. What can you say when someone says things like "We prefer logical replication because it uses less bandwidth"? There are extremely good justifications for the high bandwidth cost of real (bit-level) replication. Logical replication has uses but IMO it should be applied cautiously and sparingly. I felt all of the ASCII shrugs were justified. They signify a tradeoff that Uber made. My personal feeling is that most of those tradeoffs were bad, but what can you do. The slides shrug because you can't argue. If that's the problemset that their organization prefers to deal with, more power to them.

by merb 10y ago

It's not harder to use than MySQL. And for everything (even MySQL) the rule of thumb is: if you are not confident with the technology don't use it or let somebody else manage it.

foldr 10y ago

Sure, I wasn't making a claim about how easy to use postgres actually is. My point was that these slides give the impression (I assume inadvertently) that postgres is difficult to use by making fun of Uber engineers' alleged inability to use it correctly.

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.
cookiecaper 10y ago
My reading was less that PostgreSQL was "too difficult to use" and more that MySQL is less strict about safety. That difference is more substantial than it may sound. "An ounce of prevention is worth a pound of cure", as they say. While PostgreSQL may do things in a way that require a little extra annoyance up front, they're usually that way to prevent disastrous data integrity issues further down the line. What can you say when someone says things like "We prefer logical replication because it uses less bandwidth"? There are extremely good justifications for the high bandwidth cost of real (bit-level) replication. Logical replication has uses but IMO it should be applied cautiously and sparingly. I felt all of the ASCII shrugs were justified. They signify a tradeoff that Uber made. My personal feeling is that most of those tradeoffs were bad, but what can you do. The slides shrug because you can't argue. If that's the problemset that their organization prefers to deal with, more power to them.