6 ms·

I'm a huge Postgres fan and yes I'm probably biased towards it. I do think it's probably the best open source database out there, but I also don't love these ty

I'm a huge Postgres fan and yes I'm probably biased towards it. I do think it's probably the best open source database out there, but I also don't love these types of posts. What makes something better than another things is a whole host of things, not just highlighting one really bad case from the other side. I'm sure if the MySQL world wanted they could point out ways that MySQL is so much better than Postgres. Just look back at how long it too for us to get upsert, we're finally getting a better replication story in recent years. To take this one case and highlight it doesn't put the Postgres community in a positive light and it's a shame, because most I know within the community value good engineering work. MySQL has had a lot of people that contribute to it and has some good things about it, it might be worthwhile for us to pay more attention to where they are better and just focus on improving Postgres and leaving things at that.

danudey 9y ago
I remember ages ago (a decade? or so?) I started working at a company using Postgres for a project, and one of the things my boss asked me to do was to set up replication for the database. We had it on all of our MySQL databases, and everyone knew (myself included) that Postgres was a more serious, enterprise-y, "real" database. Well, I googled around and couldn't find anything conclusive, so I hopped into the / channel for postgres and asked about it. "Is there any straightforward replication solutions for Postgres?" It was like the early days of open source all over again. The first thing they did was challenge my needs. "Why do you need replication in the first place?" "Replication isn't a panacea you know." "Postgres doesn't have the issues that MySQL does that makes replication necessary." "Replication doesn't work well in the first place." A ton of people jumped into what had been a quiet channel to make sure I knew that replication, which postgres didn't have, was something I didn't need in the first place, most of which happened before they even knew why I was asking. After sorting through all that, a few people suggested "solutions". "Just have a cronjob rsync your data directory over to another machine every minute, and if your first server dies then you can just start postgres on the second one." Other solutions were much more convoluted. Patch postgres, add this software, manage it all yourself. And through it all, they kept telling me that I didn't need replication anyway, "but if you INSIST…". In comparison, the MySQL channel on freenode was staffed with MySQL employees and volunteers who were always happy to help you solve your problem while teaching you what you were missing and giving you resources you needed. They'd answer questions, help your configuration, and even fix your SQL queries for you, all without being condescending about it or making you feel like an idiot. And that's why I gave up on Postgres: the community. Postgres's was ridiculously hostile and self-important, verging on insecure and defensive. MySQL's was helpful, friendly, and full of resources. To this day I still hear great things about postgres, and I know it does a lot of things better than MySQL, but whenever someone writes a self-superior blog post about it I always think back to how much easier my life was by using a database where I could ask questions of the community and get useful answers.
- cbsmith 9y ago
  Meh. It works both ways. There was a time if you asked for transactions on MySQL...
  - leetrout 9y ago
    And I still don't have my DDL transactions... :) ;)
    - astrodust 9y ago
      This is a pretty huge deal in some uses cases. It makes undoing a bad migration trivial.
      - pmarreck 9y ago
        Manually cleaning up a bad migration fucking sucks. The best you can do is make migrations idempotent in both directions.
        pritambaral 9y ago
        Making migrations idempotent in both directions — when you can — is generally a good idea anyway.
    - cbsmith 9y ago
      Yeah. I built out a whole framework to get around the DDL thing. Super annoying.
- icebraining 9y ago
  As a Postgres fan, I do agree that the Postgres community has a more "RTFM attitude" than MySQL's. I personally don't have a problem with this, but I can understand that it might steer some people away.
  - h1d 9y ago
icebraining 9y ago
Just look back at how long it too for us to get upsert, we're finally getting a better replication story in recent years. Coincidentally, using those two features together on MySQL can have fun results: "Because the results of INSERT ... SELECT statements depend on the ordering of rows from the SELECT and this order cannot always be guaranteed, it is possible when logging INSERT ... SELECT ON DUPLICATE KEY UPDATE statements for the master and the slave to diverge. (...) An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is also marked as unsafe. (Bug #11765650, Bug #58637)." https://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate.html https://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate....
- true_religion 9y ago
  > An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is also marked as unsafe. Insanity. Also pretty much the reason I stopped using MySQL. I am not a DBA. A very small part of my job is actually interacting with the database, and I have to trust that statement execution will be consistent in all cases. That's something PostgresQL has been able to give for the past 10 years. MySQL is still not there yet, despite being backed by a "database" company with over $30 billion in revenue per year. If Oracle, with all their domain experience and reputation incentive can't get MySQl into a sane and stable state, then its fundamentals must be built on sand.
  - wvenable 9y ago
    > and I have to trust that statement execution will be consistent in all cases. I'm pretty sure no database engine guarantees the ordering of un-ordered SELECT statements.
  - pgaddict 9y ago
    I don't want to be bashing MySQL, but this nicely illustrates the project's approach to engineering - if there's an issue, put it into the docs as a known limitation. Furthermore, MySQL manual actually has "Restrictions and Limitations" (which is an interesting read too), yet this "unsafe" nature of "INSERT ... ON DUPLICATE KEY UPDATE" is not mentioned there. I'd say that if PostgreSQL learned something from MySQL, it's "Never accept feature that is incompatible with existing features, even if it's promised to be fixed soon."
pmarreck 9y ago
Uber had a pretty good argument not long ago on going from Postgres back to MySQL: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/
- devmunchies 9y ago
  Link to HN discussion: https://news.ycombinator.com/item?id=12166585 https://news.ycombinator.com/item?id=12166585 Many here discussed why it wasn't a good argument and that Uber just didn't know what they were doing.
- boznz 9y ago
  Ahhh Uber, the leading light on how to do things right.
  - T2_t2 9y ago
    I've never worked at that scale - I doubt many have. I am sure that all manner of incorrect decisions are required to make that level of scale work. What is the reddit thread that almost broke them? This one I think: https://www.reddit.com/r/pics/comments/92dd8/test_post_please_ignore/ https://www.reddit.com/r/pics/comments/92dd8/test_post_pleas... From memory, they do something different for just that thread, like loading it from a different cache. I am sure that is all sorts of "wrong", but being "right" and not scaling seems worse!

danudey 9y ago

I remember ages ago (a decade? or so?) I started working at a company using Postgres for a project, and one of the things my boss asked me to do was to set up replication for the database. We had it on all of our MySQL databases, and everyone knew (myself included) that Postgres was a more serious, enterprise-y, "real" database. Well, I googled around and couldn't find anything conclusive, so I hopped into the / channel for postgres and asked about it. "Is there any straightforward replication solutions for Postgres?" It was like the early days of open source all over again. The first thing they did was challenge my needs. "Why do you need replication in the first place?" "Replication isn't a panacea you know." "Postgres doesn't have the issues that MySQL does that makes replication necessary." "Replication doesn't work well in the first place." A ton of people jumped into what had been a quiet channel to make sure I knew that replication, which postgres didn't have, was something I didn't need in the first place, most of which happened before they even knew why I was asking. After sorting through all that, a few people suggested "solutions". "Just have a cronjob rsync your data directory over to another machine every minute, and if your first server dies then you can just start postgres on the second one." Other solutions were much more convoluted. Patch postgres, add this software, manage it all yourself. And through it all, they kept telling me that I didn't need replication anyway, "but if you INSIST…". In comparison, the MySQL channel on freenode was staffed with MySQL employees and volunteers who were always happy to help you solve your problem while teaching you what you were missing and giving you resources you needed. They'd answer questions, help your configuration, and even fix your SQL queries for you, all without being condescending about it or making you feel like an idiot. And that's why I gave up on Postgres: the community. Postgres's was ridiculously hostile and self-important, verging on insecure and defensive. MySQL's was helpful, friendly, and full of resources. To this day I still hear great things about postgres, and I know it does a lot of things better than MySQL, but whenever someone writes a self-superior blog post about it I always think back to how much easier my life was by using a database where I could ask questions of the community and get useful answers.

cbsmith 9y ago
Meh. It works both ways. There was a time if you asked for transactions on MySQL...
- leetrout 9y ago
  And I still don't have my DDL transactions... :) ;)
  - astrodust 9y ago
    This is a pretty huge deal in some uses cases. It makes undoing a bad migration trivial.
    - pmarreck 9y ago
      Manually cleaning up a bad migration fucking sucks. The best you can do is make migrations idempotent in both directions.
      - pritambaral 9y ago
        Making migrations idempotent in both directions — when you can — is generally a good idea anyway.
  - cbsmith 9y ago
    Yeah. I built out a whole framework to get around the DDL thing. Super annoying.
icebraining 9y ago
As a Postgres fan, I do agree that the Postgres community has a more "RTFM attitude" than MySQL's. I personally don't have a problem with this, but I can understand that it might steer some people away.
- h1d 9y ago

icebraining 9y ago

Just look back at how long it too for us to get upsert, we're finally getting a better replication story in recent years. Coincidentally, using those two features together on MySQL can have fun results: "Because the results of INSERT ... SELECT statements depend on the ordering of rows from the SELECT and this order cannot always be guaranteed, it is possible when logging INSERT ... SELECT ON DUPLICATE KEY UPDATE statements for the master and the slave to diverge. (...) An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is also marked as unsafe. (Bug #11765650, Bug #58637)." https://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate.html https://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate....

true_religion 9y ago
> An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one unique or primary key is also marked as unsafe. Insanity. Also pretty much the reason I stopped using MySQL. I am not a DBA. A very small part of my job is actually interacting with the database, and I have to trust that statement execution will be consistent in all cases. That's something PostgresQL has been able to give for the past 10 years. MySQL is still not there yet, despite being backed by a "database" company with over $30 billion in revenue per year. If Oracle, with all their domain experience and reputation incentive can't get MySQl into a sane and stable state, then its fundamentals must be built on sand.
- wvenable 9y ago
  > and I have to trust that statement execution will be consistent in all cases. I'm pretty sure no database engine guarantees the ordering of un-ordered SELECT statements.
- pgaddict 9y ago
  I don't want to be bashing MySQL, but this nicely illustrates the project's approach to engineering - if there's an issue, put it into the docs as a known limitation. Furthermore, MySQL manual actually has "Restrictions and Limitations" (which is an interesting read too), yet this "unsafe" nature of "INSERT ... ON DUPLICATE KEY UPDATE" is not mentioned there. I'd say that if PostgreSQL learned something from MySQL, it's "Never accept feature that is incompatible with existing features, even if it's promised to be fixed soon."

pmarreck 9y ago

Uber had a pretty good argument not long ago on going from Postgres back to MySQL: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/

devmunchies 9y ago
Link to HN discussion: https://news.ycombinator.com/item?id=12166585 https://news.ycombinator.com/item?id=12166585 Many here discussed why it wasn't a good argument and that Uber just didn't know what they were doing.
boznz 9y ago
Ahhh Uber, the leading light on how to do things right.
- T2_t2 9y ago
  I've never worked at that scale - I doubt many have. I am sure that all manner of incorrect decisions are required to make that level of scale work. What is the reddit thread that almost broke them? This one I think: https://www.reddit.com/r/pics/comments/92dd8/test_post_please_ignore/ https://www.reddit.com/r/pics/comments/92dd8/test_post_pleas... From memory, they do something different for just that thread, like loading it from a different cache. I am sure that is all sorts of "wrong", but being "right" and not scaling seems worse!