Competition in the database arena has never been fiercer. Remember the year 2000? Clinton was in the White House, the tech economy was booming, and Microsoft had just released SQL Server 2000. The new SQL Server release quickly broke through the wall from department-level to enterprise-level database. It hit the top clustered Transaction Processing Performance Council (TPC) TPC-C scores so convincingly that the TPC split the benchmark into clustered and nonclustered categories. Since then, however, SQL Server's main enterprise competitors have launched new releases. Now, 4 years after its impressive debut, SQL Server 2000 is invisible in the clustered TPC-C scores, which feature Oracle's new 10g database on top. And SQL Server sits in third place in the nonclustered category, with IBM's DB2 holding the best nonclustered score.
SQL Server 2000 jumped out to a quick lead in clustering for scalability, but the competition hasn't stood still. Oracle promotes its 10g clustering solution, although limited in scalability by its shared-storage architecture, as technology that midsized businesses can easily adopt. SQL Server's shared-nothing clustering architecture, while highly scalable, is complex to implement, especially for small and midsized organizations. To make SQL Server 2000's clustering work, you have to make good decisions about how to split the database between the different servers in the cluster, and not all third-party application providers are keen on making database schema changes to work in clustered environments. The industry perception is that Oracle 10g's solution isn't as complex; to add horsepower, you just add another system to the cluster. Although the reality is more difficult than that, in many cases, buying an additional four-processor system is easier to swallow than buying a more expensive 8-way or 12-way replacement system. Unfortunately, Microsoft's clustering-for-scalability story in SQL Server 2005, formerly code-named Yukon, isn't that different from SQL Server 2000's.
In addition, IBM's upcoming release of Universal Database for DB2, code-named Stinger, is threatening to steal Yukon's Common Language Runtime (CLR) thunder by letting customers incorporate .NET assemblies as stored procedures. Like Yukon, Stinger adds templates and an object library to Visual Studio .NET, letting you create .NET database objects. Stinger will support stored procedures, but at this early date, it doesn't look like it will support triggers, user-defined functions (UDFs), or aggregates. And because Stinger's .NET integration is an out-of-process implementation, it won't perform on par with Yukon's implementation. Still, the Stinger release is expected this fall, which means it will probably beat Yukon to market by at least 6 months.
Although Yukon delays aren't hurting existing SQL Server customers, the persistent postponements (the second private beta release came out in late July) are hurting SQL Server's competitive position in the market. Some SQL Server professionals have even questioned whether the extra time required to add the CLR and enhanced XML integration as well as new, more powerful management and development environments is worth it. But for SQL Server to keep up with the competition, it must address not only current database needs but also future requirements. Yukon promises to bring a lot of new firepower to the database market—and the next SQL Server release can't come soon enough.
