Before we get started, let me say that I always liked being a SQL Server DBA. My database experience started with DB2, then Teradata, followed by Oracle, and then SQL Server (and then a little bit of Sybase after that, followed by MySQL). Coming from the other databases, I found SQL Server the easiest and quickest to learn at the time, but of course, a lot of that had to do with the fact that Microsoft was really the only database vendor around then (I started with version 4.2 of SQL Server) that shipped any decent GUI management tools with their server. Take the tools away, and you basically had Sybase on Windows with the ISQL command line tool, which was not pretty by any means.

I started managing a lot more database servers with SQL Server 6.0, 6.5, and then SQL Server 2000. I was doing a lot of Oracle at the time too, but still felt that SQL Server had an edge on Oracle in terms of ease-of use. Oracle’s done a lot to improve their tools and overall manageability over time and today they are way ahead of where they were in the version 8/9i days with their 10/11g tools, but Microsoft has kept moving forward too. SQL Server 2005 came along with a little more help in the area of management, but it wasn’t as much as in prior versions. The same can be said (in my opinion) of SQL Server 2008 in terms of additional management help. But don’t misunderstand me, in my DBA days, SQL Server was still the easiest to use over all its competitors and I never thought I’d find another database server that could equal it in terms of having the total package of ease-of-use, reliability, and good performance.

But then I found MySQL.
Of course, you can say I’m biased because I oversee product management for MySQL inside of Sun, so guilty as charged there. But I do think MySQL has SQL Server beat in many respects, even when it comes to running on the Windows platform. Moreover, a lot of other folks seem to agree. When it comes to migrating away from another database to MySQL – or using another database for new applications – the #1 database platform is Microsoft, three years running according to our year-end surveys.

So why is this the case? Why should you, if you are using SQL Server today, consider moving your current applications to MySQL or use MySQL instead of SQL Server for new applications? In an article of this size, I can’t possibly cover every factor or consideration in detail, but I can try and hit the high points which hopefully will be enough. Let’s begin… MySQL on Windows? Absolutely!

Almost two years ago, I wrote an article entitled “MySQL on Windows? Absolutely!”, where I talked about how prevalent MySQL is on Windows and why Microsoft is a great platform for our database. To date, that article has been the one I have received the most comments/emails on, and every single one was positive – all those who wrote me confirmed the reliability and high-performance characteristics of the MySQL/Windows combination.

Well, two years later, the same is still true. In terms of downloads, Windows far exceeds any other platform for the MySQL Server. For example, here are some download statistics from April 2008 to April 2009 (which includes all server versions from 5.0 on up):

Now some argue and say that the Windows platform sees such a huge increase over our other supported platforms because developers/DBAs download and develop on Windows and then move to Linux or another platform for production. And this is certainly a valid point. However, in our most recent global survey, we asked the question what production platform people use for their MySQL database, and for MySQL’s enterprise paying customers, 54% said they used MySQL/Windows for development purposes, but 32% said they deploy production MySQL databases on the Microsoft platform – the 2nd most popular platform (RHEL was #1). Perhaps more surprising, the MySQL Community stated they use Windows for development 65% of the time and deploy MySQL production databases on Windows in 44% of their roll-outs, making it the number one platform for both development and production. You can see a general online quick poll we did on this subject here: http://dev.mysql.com/tech-resources/quickpolls/primary-os.html.

The point is, if you’re sold on the Microsoft platform for your data center or various stand-alone systems, then you’ve got plenty of company in using MySQL on Windows. And, of course, unlike SQL Server, if you want to move to Linux, Solaris, or other operating systems with MySQL, you certainly can.

Installing and Configuring MySQL vs. SQL Server
Although installing software isn’t a major factor when looking at databases, it can still come into play if you have many servers that you commission and upgrade. The last SQL Server 2008 Enterprise download I utilized was 1.6GB in size with another download required for a new .NET framework install, which ironically, was the same size as the full MySQL 5.1 GA install for Windows – 150MB. I can install MySQL on my WIN boxes and be at a MySQL command utility prompt in under 5 minutes, but a SQL Server install takes much longer (with your mileage varying depending on the server you use). Just the .NET framework install took more than 5 times the installation time of the MySQL Server on one of my test machines.

But as I said above, installation isn’t a big consideration with databases. And some may think that they small size of the MySQL WIN download is indicative of the fact that the database server isn’t very feature rich and therefore that’s why it’s so tiny. We’ll more fully dispel that myth later in this article, but suffice it to say that such an assertion is false. Good things do come in small packages, as they say. One of my favorite examples to illustrate this point is one of our partner storage engines – InfoBright. Their MySQL-based data warehouse engine is only a 17MB download, installs in about 3 minutes, and can mange up to 30TB of data on a single server with incredibly fast response times.

Another install and configuration consideration is having multiple instances of a database server on one machine. This is another area where I find MySQL easier to use/manage than SQL Server. For me, it’s a cakewalk to have multiple instances of either the same version of MySQL or different versions of MySQL on the same box. All that’s basically required from a ‘tweaking’ standpoint is that you (a) install different versions of MySQL in different directories and, (b) use a different connection port (MySQL’s normal default port is 3306) for each MySQL install if and only if you want to run multiple instances of the database server at the same time.

I also like the fact that I can have a full-featured MySQL Server install on my WIN XP machines without having to use Windows Server like is sometimes required for various versions of SQL Server Enterprise.

Lastly, when it comes to configuration, most SQL Server DBAs set their config parms via the SQL Server Management Studio whereas MySQL DBAs manually edit the my.cnf file. Note that, like SQL Server, most of the config parms for MySQL are dynamic and can be set/immediately changed via a SET GLOBAL statement at a MySQL command line prompt.

Comparing Core SQL Server and MySQL Features
To me, the release of SQL Server 2008 was more impressive from a new feature introduction standpoint than SQL 2005, although 2005 did have some very welcome new enhancements such as Microsoft’s first cut of table and index partitioning. But SQL 2008 brought out some solid features I find very compelling such as parallel support for partitioned objects, transparent data encryption, resource governing, automated performance data collection, change data capture (CDC), and more.

With MySQL, we never engage in database feature wars because that’s not our goal – adding features and becoming as large as Microsoft or Oracle in that regard is not what we’re about. Our three priorities are reliability, performance, and ease-of use, with features only being added when we believe they will strengthen those main concerns. Now that said, there certainly are times when various esoteric database features are necessary for an application, but those times are often the exception rather than the rule with even Forrester Research stating that 80% of the current database installations only make use of around 30% of the vendor’s feature set. I can echo that conclusion from my personal experience in using SQL Server – rare was it that I actually used some of the more boutique features of the database server; most times it was the core RDBMS feature set that powered my applications.

Now you may think I’m setting you up for a letdown with the previous paragraph – that MySQL isn’t going to deliver when it comes to the features you’ll need to move from SQL Server, but you’d be mostly wrong. When I first began transitioning some work from SQL Server to MySQL a number of years ago, I was impressed with the feature set I found then in MySQL, and it has only improved since that time. If you’re unfamiliar with the MySQL feature set, I can’t possibly list everything included in MySQL in an article of this size, but here’s just a sample of how MySQL stacks up to SQL Server (latest versions of both) from a feature standpoint:

Full article...