Why Should You Use MySQL?

<i>Personally I prefer PostGreSQL over MySQL for a drop in replacement on Linux based systems. It’s far superior in many ways, and something you should consider if you’re able to. Personally if I were to start a new business or had a Linux based environment and was in the planning phase I would choose PostGreSQL from the start. But it’s not always the best option for most people.</i><p>What a crappy defense.<p>There is little I like about MySQL but here's a few reasons I still recommend people use it:<p>1. It's already part of something delivering value to your business. E.g. Nagios, MediaWiki or some other LAMP stack solution you've deployed. It's there. You're using it. Learn to live with it, and be sure to BACK IT UP!<p>2. You need to work with data someone gave you that came from a MySQL system. E.g. a Wikipedia dump. Someone else already lived the pain of collecting data into MySQL, now all you need to do is refine it.<p>3. You're publishing data for someone else to load into their MySQL system (e.g. a Pentaho warehouse).

MySQL is to Postgres today as mSQL was to MySQL in 1998; more popular yet technologically inferior. In another 15 years, we will be having the same arguments about PostgreSQL and the thing that comes to replace it, whatever that may be.<p>MySQL is in production and we have to live with it. The defences in the linked article are all valid. MySQL is a very sharp tool and can be used effectively. But its time has passed. Start your new projects on a more solid footing.

1 reason to use MySQL rather than Postgres:<p>1) Your legacy shared hosting site might provide MySQL and not Postgres.<p>There are also 9 reasons to choose one of {Postgres, MySQL} over {Oracle, SQL Server}.<p>Here is 1 reason to use Postgres: data integrity.<p>"00/00/0000 00:00:00.0000" is not a real date, but MySQL will helpfully insert it into your table if you try to insert NULL into a non-null datetime field. (One example among many.)

&#62; You don’t need to hire a group of certified DBAs to run a MySQL database. An ordinary programmer can learn enough to maintain their database servers for most applications.<p>There is a reason why I, as someone whose experience in principally in data management, does not "write applications" - I might be able to write something that works, but it will likely lack security, stability, scalability. The same things happen with app developers, without an equivalent of database expertise, will make similar mistakes.<p>You may need a team of "certified" DBAs, but you need someone to guide the development of a stable foundation.

These are all reasons why you'll do fine with MySQL if you're stuck with it, but they don't give a compelling reason to choose MySQL over e.g. PostgreSQL.<p>One thing I like about MySQL is the support available from third parties like Percona - I'll also recommend the book "High Performance MySQL", which gives some great details on performance tuning and query optimizing.<p>I'm not familiar with the offers for PostgreSQL - I'd like to hear what support services and books people with PostgreSQL experience would recommend.

I was just going to submit this and found it was already submitted, thanks. Curious to see how others are going to tear my case apart on this one.

Yes...this.<p>Another thing that is often overlooked is tiered slaves in conjunction with logical replication for adding OLAP to an OLTP infrastructure. This allows you to have additional reporting data on slaves that is not present on the master and along with real-time replication, eliminating or simplifying nightly batch processing. This also allows you to keep a very small working set available on the master database with slaves that contain the full archive. In conjunction with BLACKHOLE tables, this can be very powerful.

I was expecting a more compelling case.

RDS as a scaling strategy is also a good reason.