Your equality of MSSQL and MySQL backups is misleading. MSSQL backups can be easily made and scheduled. They can also easily be compressed, have old copies removed after some rotation period. MSSQL has 3rd party plugins (Backup Exec, DPM...) for backup that can easily integrate with file system backups. Backups in MySQL have to be scripted and scheduled with another package.

Also MySQL's analytical capabilities are non-existant. Most of the other big players have an OLAP engine - MySQL has none. 

Having used all the big databases, (Sybase, Oracle, MSSQL, DB2, Informix, MySQL) I can say without a doubt that MySQL is very useable, but not at all comparable to the big guys. MySQL's best use is in a shop where you have infinite programmer skills and no DBA's. It is cheap, but you will pay for its cheapness when you have to have script every single administrative task.

Given MySQL's shakey future, I would not recommend it for large shops.

One should also note that MySQL is only ACID compliant when the INNOUDB option is employed.  Otherwise it is not ACID compliant as any change made to the database is immediately visible to anyone else.  MySql's intent is to be fastest on data retrival thereby making inserts, updates, and deletes slower.  Even though I'm no fan of MSSQL I feel it is a superior product by far to MySQL.  And even MySQL's dual licensing model is confusing to beat the band.  Lets face it your either Open Source of Not.  In this case MSSQL presents a better defined model.  Actually if you want a product in the open source world to compare MSSQL with try PostGreSql.

The article focused entirely on administrative functions, some of them not particularly important to me as part of a small company with relatively few transactions.  There are a lot of major programming and analytical features that weren't even touched on that I find very useful, such as CLR integration, Analysis Services, Reporting Services, etc.  Nor were differences between the latest T-SQL and whatever MySQL uses (hey, I know little about MySQL) discussed.

Microsoft have just released a mySQL migration assistant:

http://www.microsoft.com/downloads/details.aspx?FamilyID=0e6168b0-2d0c-4076-96c2-60bd25294a8e&displaylang=en

 You have to separate the marketing bumpf from the reality.

 The guys who wrote MySQL will tell you that it was never designed for the purpose that a lot of people are now using it for. One engineer told me that anyone pushing beyond 200GB in a single database instance was going beyond the intended capacity for the system.  MySQL focuses on scale-out DB designs to achieve huge sizes with realistic performance.

MySQL Cluster is an in-memory share nothing engine that requires a specialised design approach.  If your query can satisfy data from the same node in the cluster then it is very fast.  If your data is spread across the nodes in the cluster then performance is poor.

You have to design for the shared-nothing architecture.  Nice work by Johann Anderson though to have built such a system.  It's brilliant for key value lookups and, having been written specifically for Ericson, it is extremely useful in the telecoms industry.

 MySQL was designed for small to medium web sites and it is very good at servicing these requirements.  Factor in the cost and for a small business startup it is a very attractive proposition.

 In terms of performance if you install MySQL and SQL 2008 on identical hardware and Windows2008 then SQL2008 wins hands down.  MySQL can get to about 90% of the performance only after a lot of tuning by people who know what they are doing.

That said do you really need the performance?  It is like comparing a Ford Focus with a Ferrari.  How many people can drive a Ford Focus to its limits, much less a Ferrari?

Stored procedures in MySQL are simply parameterised units of code.  There is no concept of a cached execution plan.

Foreign Key support in MySQL works in InnoDB but it has a performance hit due to the pluggable engine architecture and the layer in which FK support is executed.

 There are no check constraints in MySQL.

Without clever design I think you will outgrow MySQL and start looking at one of the big boys in the DB industry.  If you are a Windows shop then MS SQL is an obvious choice.

If you are one of the *nix guys then there are a plethora of choices.

Last time I looked at MySQL I was a bit surprised to find that it would discard data with no warning or error. This was using the InnoDB. Mind you it was a few months ago so things might have changed now.

Although I tend to agree with some of the comments in regard to what MySQL was originally created for, I am more concerned now on how both servers (MS-SQL vs. MySQL) perform when compared head-to-head, doesn't really matter why they were created IMO.

Both servers gone through a lot of enhancements, I have been working with MS-SQL since it was first acquired by MS from Sybase, and feature wise, lol, don’t even get me started there, it was nothing compared to what it is now. The jump from SQL 2k to 2008 is also considerable; the notorious problem of table locking in MS-SQL 2k is enough to consider 2008 performance considerably superior to its predecessors.

On the MySQL side, Oracle would have never bought it if it wasn’t being threatened by its spread in the Internet community. I have to point out though that no matter what super-doper DB engine you use, a poor table index design on the DBA side can render your database worst of the worst compared to any other available engine.

I have recently conducted a MySQL vs. Ms-SQL performance test (check it out here), that is not by any means scientific, but at least it did the job for the case I had in hand. It shows that no matter what engine you use, performance can significantly vary depending on table structure, db size, etc.