4 ms·

It feels like PostgreSQL is at the center of every terrible story about data loss[1] or poor performance[2]. I think companies prefer other databases like MySQ

by pdog 10y ago

It feels like PostgreSQL is at the center of every terrible story about data loss[1] or poor performance[2]. I think companies prefer other databases like MySQL because they "just work." [1]: https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/ https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-... [2]: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/

sgarman 10y ago
Seems like confirmation bias. I always think of nosql databases when I'm thinking about terrible data loss stories, I especially remember the couchDB one. Postgres has been nothing but amazing for my uses.
- patmcguire 10y ago
  If you delete your data directory, you're going to have a bad time no matter what your stack is.
  - VintageCool 10y ago
    Yes, it's probably an outage event, but then you flip over to your slave MySQL instance and keep going on your merry way.
AlisdairO 10y ago
You gave one example of each. That's a pretty painful definition of the word 'every'. On performance: Every database will have some areas where it performs better than others - Uber just happened to hit a case that MySQL is well optimised for. On data loss: MySQL's binlog replication is hardly a 'just works' solution. It's definitely got a lot better over time (particularly in 5.7), but it's not like a replica falling behind is some incredibly unusual event. Go back a fair while and it was really broken - much more so than Postgres' solution has ever been. It's fair to say it's more mature right now, and one reason to prefer MySQL for replication is that there's certainly more help out there for it.
pritambarhate 10y ago
I had used MySQL replication with Wordpress around a year ago to keep a standby DB in another data center. The replication used to break almost every 4-5 days. The data loss in this incident was human error, not PostgreSQL fault.

by pdog 10y ago

sgarman 10y ago

Seems like confirmation bias. I always think of nosql databases when I'm thinking about terrible data loss stories, I especially remember the couchDB one. Postgres has been nothing but amazing for my uses.

patmcguire 10y ago
If you delete your data directory, you're going to have a bad time no matter what your stack is.
- VintageCool 10y ago
  Yes, it's probably an outage event, but then you flip over to your slave MySQL instance and keep going on your merry way.

AlisdairO 10y ago

You gave one example of each. That's a pretty painful definition of the word 'every'. On performance: Every database will have some areas where it performs better than others - Uber just happened to hit a case that MySQL is well optimised for. On data loss: MySQL's binlog replication is hardly a 'just works' solution. It's definitely got a lot better over time (particularly in 5.7), but it's not like a replica falling behind is some incredibly unusual event. Go back a fair while and it was really broken - much more so than Postgres' solution has ever been. It's fair to say it's more mature right now, and one reason to prefer MySQL for replication is that there's certainly more help out there for it.

pritambarhate 10y ago

I had used MySQL replication with Wordpress around a year ago to keep a standby DB in another data center. The replication used to break almost every 4-5 days. The data loss in this incident was human error, not PostgreSQL fault.