SQL Server 2005: Late but Loaded

Two weeks ago, I wrote about the delay of SQL Server 2005, formerly code-named Yukon (see "Yukon Delays"). Microsoft has pushed back commercial availability of SQL Server 2005 to the first half of 2005, presumably closer to June than January. In my earlier article, I asked you to share what effect SQL Server 2005's delay might have on you and your organization. This week, I summarize the responses many of you sent me and share some of my thoughts about the delay.

Most readers who sent their responses said the delay won't be a major problem. Many of you prefer waiting to getting a release plagued with significant bugs. Readers noted that SQL Server 2000 has made great strides in gaining enterprise acceptance. However, if customers had to wait to deploy SQL Server 2005 until Service Pack 1 (SP1) fixed major problems in the release, the effect on the perception of SQL Server as a quality product would be disastrous. "The delay is a confidence booster for us," one reader noted. "We interpret the delay to mean that Microsoft is determined to produce a quality product."

Microsoft does want to produce a quality database platform. Many customers don't know that Microsoft rolls out one of the SQL Server final betas to its internal production systems. In addition, several customers will roll out the beta in production as part of the technical adopter program (TAP) before SQL Server 2005 is released to the public. In other words, Microsoft and several large customers will be running their businesses on SQL Server 2005 before the commercial release.

On one hand, readers want a quality product. On the other hand, readers agree that the reasons behind the delay stem more from Microsoft's ambition to add certain new functions than from quality issues. Many readers believe Microsoft is too concerned with developer-oriented features, such as Common Language Runtime (CLR) integration, rather than focusing on core data-management enhancements. From the responses I received, most readers agree that a release between SQL Server 2000 and SQL Server 2005 that didn't contain the CLR but that featured enterprise data-management and T-SQL enhancements would have been a better strategy. One reader put it this way: "Microsoft continues to try and build an enterprise database server product and, at the same time, entertain the development community with 'shiny baubles' that make it nearly impossible for a DBA to keep a server up and running with four nines and three quarters of a million transactions per hour."

Although that statement represents a typical DBA perspective, the developer world might feel differently. A developer might be willing to wait for the tighter integration with .NET. In my opinion, Microsoft is following a wise path by making aggressive moves to increase developer productivity within the database space. You can't have enterprise-class applications without highly reliable and scalable databases. At the same time, the database exists to serve applications (although DBAs sometimes forget that). Is the CLR good for SQL Server? Yes. Was focusing on developer needs in addition to DBA and core engine needs the right thing for Microsoft to do? Yes. Was the developer focus around .NET worth adding 1-3 years to SQL Server 2005's development cycle? No. But hindsight is 20/20.

I talked with Tom Rizzo, Microsoft director of product management for SQL Server, about the SQL Server 2005 delay. Tom admitted that there was a lot more work involved in building the feature set for SQL Server 2005 than originally planned. In addition, the development team took a significant hiatus from SQL Server 2005 to go on a search-and-destroy mission for security vulnerabilities in SQL Server 2000. Tom agreed that a release between SQL Server 2005 and SQL Server 2000 might have been in Microsoft's—and its customers'-best interest. However, he was adamant that SQL Server 2005's rich feature set, including the developer enhancements, is the right long-term approach for the database world. "You don't make great strides in computing by taking tiny steps," Tom said. And I agree.

Perhaps Microsoft should have anticipated a longer development time for SQL Server 2005 considering the number of features being introduced. But making a big leap in the database space is a good long-term strategy for Microsoft and its customers. As long as Microsoft ensures that the product will be reliable at ship time, I don't have a problem with the delay—and most of you agree.