For our soon-to-be-hosted application I need to choose between SQL Server 2008 Web edition and SQL Server 2008 Enterprise edition. There isn't any "must-have" functionality: the application currently runs on SQL Express, but it will exceed the 10GB maximum size that SQL Express imposes.

I'm looking at this comparison chart, and the most significant table in this page "Scalability & Performance". As tables get larger, functionality like "Table and Index Partitioning" would be vital to guarantee performance speeds. But at what table sizes would this be required?

What strategies should I use to determine if the size and usage of my database requires the Enterprise Edition Scalability and Performance functionality?

2 Answers 2


This is a very tough question to answer and the only correct thing to say is "it depends". Yes, it's trite but that doesn't make it untrue. That being said I'll try my best to give you an answer (use Standard) and explain the thought process behind it.

I'm not familiar with the "Web" Edition of SQL but I can certainly rattle off the differences between Standard and Enterprise. At the risk of a massive generalization I'd say that if you're looking at between 10 and 100GB for a single DB and you're not sure you need Enterprise features, the upfront cost difference combined with the ease of upgrading the SKU (Edition) if/when you need to mean that choosing Standard over Enterprise probably makes the most sense. I'm guessing that "Web" edition is some semi-stripped down Standard version and personally I'd avoid it based on the "Web Workloads Only" disclaimer. What does that even mean?!

So how does one truly determine if they'll need Enterprise features? Well, the best way I can think of is to download the Standard and Enterprise trials (or get an MSDN license) and do performance testing with both editions. If you find you can't hit/exceed your performance targets with the lower edition identify the bottlenecks and then see if the Enterprise features would assist. If so, upgrade & make the needed changes to use the features then re-test. In my experience the main features one makes use of in Enterprise are (in order of most common to least):

  • online reindexing
  • row/page compression
  • backup compression
  • filtered indexes
  • partitioning & partitioned indexes
  • indexed views
  • parallel index operations

And finally... When moving up from something that's running well on SQL Express I don't think there would be many cases that justify the jump to Enterprise. Alone, the additional system resources that the full version of SQL can use should deliver big gains.


Features like table partitioning are typically only used in data warehouses were you have billions of rows to deal with and you want to control which disks each part of the table is stored on.

Data size doesn't really matter between web and enterprise. There are lots of people running very large databases on standard edition (I don't know of anyone using workgroup or web edition). The biggest changes are the amount of memory that you can assign to the SQL Server. The more memory the better, as the more memory you have the less you'll be going to the disk for data.

For you the biggest selling point between Web and Enterprise edition will be the online index rebuilds that you get with Enterprise Edition. If you can afford to take the outage nightly (or weekly) to do index rebuilds (or you can get by with index defrags) then stick with the web edition until you have a need to upgrade, or when the outage required to do the index rebuilds is to long.

Update 11/28/2011 Something new to keep in mind is that the Web edition will only be available via a hosting provider like RackSpace starting with SQL Server 2012 and the Workgroup edition will be going away. So if you'll be buying a license at this point you'll want to go with Standard or Enterprise. I did a big writeup on the SQL Server 2012 licensing (here as well) which covers all the changes that you'll want to be aware of.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.