[dcolgan]

Is there a good reason to use MySQL when you have the choice between it and Postgres? When we had the MySQL vs Postgres discussion in college, it seemed like the only reason to use MySQL we could come up with was that it had the larger user base.

[spudlyo]

Traditionally MySQL has been ahead of Postgres in terms of replication, but Postgres has made great strides in that department recently. Having said that, Postgres still doesn't support master-master or ring topologies, replication filtering, and is binary only (which is probably a good thing).

[fdr]

Naah, I wouldn't go so far to say it's a good thing that it's missing, but it's hellaciously hard to implement well. I think the sentiment is rendered well in this mail, which took place after extensive review and hacking. In it, Robert Haas (a committer) writes to Andres Freund (the principal author, I believe):

  Before getting bogged down in technical commentary, let me say this
  very clearly: I am enormously grateful for your work on this
  project.  Logical replication based on WAL decoding is a feature of
  enormous value that PostgreSQL has needed for a long time, and your
  work has made that look like an achievable goal.  Furthermore, it
  seems to me that you have pursued the community process with all the
  vigor and sincerity for which anyone could ask.  Serious design
  concerns were raised early in the process and you made radical
  changes to the design which I believe have improved it tremendously,
  and you've continued to display an outstanding attitude at every
  phase of this process about which I can't say enough good things.
  There is no question in my mind that this work is going to be the
  beginning of a process that revolutionizes the way people think
  about replication and PostgreSQL, and you deserve our sincere thanks
  for that.
 
  Now, the bad news is, I don't think it's very reasonable to try to
  commit this to 9.3.  I think it is just too much stuff too late in
  the cycle.  I've reviewed some of the patches from time to time but
  there is a lot more stuff and it's big and complicated and it's not
  really clear that we have the interface quite right yet, even though
  I think it's also clear that we are a lot of closer than we were.  I
  don't want to be fixing that during beta, much less after release.

http://www.postgresql.org/message-id/CA+TgmoYhkMpkB8JZYhVei-...

The implications for PostgreSQL version upgrade alone are enormous. MySQL has been ahead here, even though some if it was at the cost of some sanity, and by lack of sanity I mean "statement based replication". The first semi-sane logical replication was the 2008 release that included row-based-replication.

[arjn]

We use both in our production and staging environment. I've been using both for the last 3 years (5 years for MySql). My opinion at this time is that in 80% of cases MySQL is easier to setup, use and manage.

[saosebastiao]

Only if 80% of the use cases are extremely simple use cases, with no need for multiple indexes per table, complex queries, common table expressions, user defined datatypes, window functions, asynchronous queries, or a strict stance on undefined behaviors, etc.

The problem I see is that simple use cases gradually become slightly-less-simple use cases. And the pain of switching is 1000x the pain of taking a few extra steps up front and using a better database.

[rimantas]

I doubt all the stuff you listed is used even in 1% of cases, except multiple indexes and strict stance. And MySQL supports both.

[saosebastiao]

All the stuff, sure. But I have yet to find a scenario that doesn't involve at least one of them.

[agildehaus]

The only one I can come up with is that Sequel Pro supports MySQL and not PostgreSQL.

Truly, the one item I miss the most from making the switch.

[andyana]

I've been using both for 10 years; postgres for in house apps, my SQL when a third party app needs it, and I find postgres much easier to manage.

[sidmitra]

I prefer Postgres wherever i can, i usually go with MySQL(or RDS) whenever i'm on AWS. Since the added features of multi-AZ, and scalability take a lot of upfront effort/time investment away.