What Does the Death of Alpha on NT Mean to SQL Server?

Forget Intel Inside. From now on, Intel Everywhere is the phrase du jour if you're managing servers that run Microsoft OSs. During the last few weeks, both Microsoft and Compaq have declared Alpha persona non grata in the land of Windows NT. Compaq is dropping Alpha support for the current version of NT, and Microsoft has announced that it won’t support future releases of NT on the Alpha platform. This announcement means that future versions of SQL Server will run only on Intel chips. Of course, the $64,000 question is, does it matter?

I don't know what brand of spark plugs I have in my car, and I have no idea who Ford outsourced its engine production to. I could have a bunch of hamsters running around under my hood for all I care. Does my car run and do what I expect? That's what matters to me. Does it really matter what brand of CPU is inside your server? I don't think so. What matters is price, performance, and reliability. After all, how many of you know who manufactured the memory, disk drives, SCSI controllers, and other components inside your servers?

For some reason, the people who buy NT servers never adopted the Alpha platform, and I'll never understand why. Several years ago, a huge performance gap existed between CPU performance of top-end Intel and Alpha chips. Hungry database servers crave CPU cycles, so Alpha-based servers seemed like a natural choice for people looking to squeeze every drop of performance out of their SQL Server boxes. Unfortunately for Digital Equipment, no one cared or bought. Most people kept buying Intel, usually without considering whether Intel Inside was right for them. Of course, Microsoft shoulders much of the blame for the groupthink that led people to shun Alpha. No one was ever going to believe Microsoft cared about platform independence for NT when most Microsoft software for NT didn't ship with native Alpha binaries.

Over the years, Intel closed the performance gap, and people began caring less about platform independence for NT. After all, you probably wouldn't be running NT in the first place if true openness and platform independence are your primary goals. The Pentium architecture has posted dramatic performance improvements, and Intel’s 64-bit Merced chipset is looming right around the corner. As a result, the performance imperatives for using 64-bit Alpha are seemingly less and less important.

I'm sure many of you will disagree, but I don't think losing the Alpha platform poses any serious threat, at least for today. Intel chips are fast, reliable, and inexpensive, and that's what matters. But I'm worried about the future. Intel is now the only game in town for NT. Will Intel get lazy and complacent because it has no serious threat in the high-end Microsoft server market? Only time will tell. On another front, today Microsoft will certainly claim it plans to maintain potential platform independence by protecting the integrity of the hardware abstraction layer (HAL). That's easy to say, but will it be as easy 18 months from now? Will Microsoft decide it needs to cut a few corners here and there when designing 64-bit NT? Will Microsoft want to squeeze out a few extra percentage points of performance by writing directly to Intel-specific architectures? I hope not, but again only time will tell.

I've beaten this drum before, but in my opinion, database performance is usually a function of how your application interacts with the server rather than being a back-end issue. If you want a fast database, you must understand how your application talks to the server, and this often means having a good working knowledge of ADO. Morris Lewis and Ken Spencer both have excellent articles on ADO in the September issue of SQL Server Magazine. Morris's article even includes a handy tester application that will help you see how changes to ADO cursor settings will affect server-side activity. Just one more reason to have a subscription to SQL Server Magazine!