A Closer Look at Application Scenarios
Thinking in abstracts sounds too much like marketing jargon. I prefer looking at specific scenarios. Like I mentioned, I try to use the right tool for the job rather than show unquestioning loyalty to one product regardless of the application. With that in mind, here are some of the development scenarios ISVs face in which SQL Server and the Microsoft stack make more sense.

1. You're building a heavy XML app.
PHP/Perl scripting gives you plenty of nice XML functionality when using MySQL. But in terms of full-blown XML support, you'll need SQL Server Express for native XML data types, indexing, full-text XML search, and XQuery. MySQL has none of these features.

If you're building a page with asynchronous functionality, then you may have JavaScript calls to a Perl script, just as an example. The Perl queries your MySQL database and returns a data set, which gets parsed into XML usable by maybe some third-party Ajax functions (assuming you're not doing JSON). This looks pretty straightforward.

But now consider extensibility. What if you want to extend this functionality to a mobile device? Or a Windows Vista gadget? Or call your Perl script as a Web service in a future as yet unimagined application? Most likely you'll be stuck rewriting the code. Here's where one of the unseen benefits of SQL Server comes into play. For the same amount of dev time (if not less), you can build a simple C# Web service that pulls native XML from your SQL Server database, instead of using Perl/MySQL. The result: with this one change you have the flexibility to incorporate that service into other apps, including other Web services. Your JavaScript calls work the same, but now you've created a foundation for creating, and upselling, new products and services based on your efforts.

2. Your customer needs Business Intelligence, including reporting and analysis.
If you're building a high-transaction database, you almost certainly need BI tools to go with it, whether the customer is an external client, and internal client, or you. Because of MySQL's streamlined functionality, this would be considered a third-party partner opportunity. In other words, MySQL doesn't have BI tools, but they know someone who does.

To be honest, if you're just doing a straight apple-to-apple comparison, you won't find much more with SQL Server Express. You have some SQL analytical functions and query optimization, but that's about it. That is, until you discover the SQL Server Express Toolkit, which includes Connectivity Components, Business Intelligence Development Studio, Management Studio Express, and a Software Development Kit. The Business Intelligence Development Studio alone is worth the download. This free extension for Visual Studio gives you extensive reporting and analysis services like report wizards, multiple data mining models, and data cubes.

Also, as with the other scenarios, your feature list grows when you scale up. For example, SQL Server Workgroup edition adds the BI Development Studio natively, as well as enterprise management tools and a report builder, among other services. SQL Server Standard edition goes on to add data warehousing, data analytics, Unified Dimension Modeling, and nine different data mining algorithms. Enterprise edition, of course, adds another dozen or so BI services on top of that.

3. You're deploying your app on multiple Windows platforms.
While MySQL comes in an embedded version, when it comes to integrating throughout the stack, it can't begin to compete with SQL Server. SQL Server CE (Compact Edition), which replaces SQL Server Everywhere, uses a sub-set of T-SQL, integrates into Visual Studio, and offers developers a familiar framework and syntax for building distributed mobile apps. Redistribute CE whether you're building a standalone mobile app or syncing with SQL Server 2005 in a client/server architecture. Whatever configuration you dream of can be managed in the same integrated development environment.

4. You need to prepare for wild success and high scalability.
No doubt you can think of many stories in which innovative new sites become victims of their own success by failing to scale. That can still happen using SQL Server, obviously—if you build the next MySpace, then at some point you'll hit a few bumps en route to becoming a gazillionaire. But the high scalability of SQL Server Enterprise Edition gives you performance beyond read-only or read-mostly transactions. It scales to 128 CPUs and offers distributed partition views and cross-disk filegroups. So you can code your prototype on the Developer Edition, bump it up to Standard for deployment, then up to Enterprise as demand increases. In fact, that's one of the reasons MySpace itself migrated to the Microsoft Web platform, including SQL Server 2005 and ASP.NET 2.0.