I don't know why anyone in 2015 would pick mysql when postgres is an option. Live postgres. So nice to work with. It's json support is amazing too
I am in the "pro Postgres" camp, but this attitude is too black and white for me. For many projects Postgres in superior to MySQL, but there are situations and requirements where MySQL makes a lot more sense.
For just one example, I can get MySQL as a service much cheaper and easier than I can get Postgres as a service. Which isn't to say Postgres as a service doesn't exist (it does), just to say MySQL is more readily available and there is more competition in that sector.
Additional if I had a DBA who was a MySQL expert and didn't know a thing about Postgres, I'd go with MySQL for my project. Since a good DBA is worth their weight in gold, and an expert in a particular DBMS can be a massive asset to a project.
But given no restrictions or needs, I'd pick Postgres as my "default" choice. I just don't think it is right to say you'd avoid a team/project just because they picked MySQL, sometimes there are completely legit reasons (or politics).
Example:
select COUNT(1), status FROM some_table GROUP BY status ORDER BY status; -- Postgres 10x slower.
I thought I was doing something wrong, so I asked on SO:
http://stackoverflow.com/questions/32755348/group-by-count-q...
This is a very simple example, but I always run into major performance issues with Postgres. Some of them are my fault, from not knowing that array aggregation is a slow operation.
MySQL advantages for me are that there is an actual UPSERT operation (an inferior version of which might be added to Postgres 9.5), that the CLI is miles ahead, and that it's much faster for a small number of tables with a lot of data and with non-complex operations.
I would add, you should really upgrade to 9.4, as there were some performance improvements to aggregates.
I am not sure in which cases the MySQL one doesn't work correctly. ON DUPLICATE KEY UPDATE checks every unique fields in table, not just PRIMARY key.
Also, I'll try these suggestions, but you can see that it can be frustrating that simple queries don't work quickly or randomly work really slowly and you have to find some configuration settings to hand tune.
It's quite possible this is just due to people supporting existing applications, but I dunno, I am tempted to stick with MySQL for new stuff for the next little while.
There's also a lot of NoSQL solutions that are being ever more widely used. Most of which have much lower costs for HA early on.
Looking at trends can help you:
- See how easy hiring people will be in the future.
- See the likelihood that your chosen framework will lose support.
- See the likelihood of third party support/addons/libraries/etc.
- How easy it will be to find help/tutorials/guides/etc.
But looking at it, to me, seems prudent.
If you care about your data and would rather not deal with the many problems MySQL inevitably brings, then Postgres is the better option. I can't say I've seen many compelling reasons to use MySQL over Postgres other than "what if we need to replace you with a freelance PHP guy", "I want to pay lower wages", and "I want to use phpmyadmin". (Btw: check out Sequel Pro and Querious!)
Popularity isn't a very good reason to choose something. Postgres will remain a juggernaut for a long time. Unless you really think there's a good chance you'll need to hire somebody that only knows MySQL, then I'd go with Postgres.
Postgres, MS-SQL, Firebird, Oracle, DB2 are all better options in my mind... unless you need a good replication story, without a pricey support contract, then Postgres and Firebird are sadly out of the running imho.
It's popular at scale because unlike Postgres, it has replication that is well understood, is reliable, and isn't a massive pain in the ass to operate.