In order to save licensing costs I'm evaluating whether I can get away with Standard Edition for a VLDB. I'll outline the scenario:

  • Here, "VLDB" means 5TB.
  • The size is expected to be stable over time.
  • Almost all data would be in a single table.
  • The query and DML pattern is a key-value type of scenario. There are only single-row accesses by primary key.

I wonder what I would need Enterprise Edition for. I would not derive any benefits from partitioning because I don't want to switch partitions or place them on different storage. Data compression could save us maybe 50% but we use cheap storage. The saving would be insignificant compared to the expensive license.

For HA I don't see why I couldn't go with the deprecated but still working Mirroring. That's not ideal but Enterprise Edition is a high price to pay for unclear benefit.

Still, it makes me nervous to use Standard Edition here because it is not what's generally recommended and it seems vaguely risky. Looking for some advice on this situation. Thanks!

  • 1
    Data compression isn't just about saving space but also saving I/Os, meaning better performance. Important with cheap (cough, slow, cough) storage media. – Daniel Hutmacher Feb 19 '16 at 17:47

Here is my two cents in the form of an answer...

Kin pointed out the CPU and memory limitations of standard edition (16 cores/4 sockets and 128GB - though see Buffer Pool Extension), which I completely agree with being the largest obstacle. If you're server is going to be under those requirements then it's a moot point.

Aaron pointed out that if you use SQL 2016 you'll get a less flexible form of AGs. Honestly, to me, it doesn't sound like this will work for you. Cheap storage would be the death of it and if you're considering standard edition I highly doubt this database is that important. Not saying all important databases need to be enterprise edition - but the fact that you're in cheap storage and looking at SE says it all.

Additionally you're not looking at any enterprise level features which could help you. Range partitioning the key/value pairs, compression, column store indexes on the KVPs, TDE/AE, etc.

So, it seems, at the end of the day you're looking for someone to talk you INTO using enterprise edition. I don't know what the usage patterns of the database are, the load, or what it supports for the business... so unless it requires more than the CPU/Memory of standard edition I see no need with the information provided to go with enterprise edition.

The last thought is if this will be virtualized - if so, depending on licensing (enterprise of the host[s]) that's where it may make sense. This wasn't included in the discussion so I'm just throwing it out there.

See also: Features Supported by the Editions of SQL Server 2014

| improve this answer | |
  • These are some good thoughts. I certainly do not want to be talked into EE. Rather, bigger databases usually run on EE AFAIK which makes me uneasy that I might overlook some important concern. I do not want to find out something important is missing a few weeks after going live. – boot4life Feb 20 '16 at 12:21

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.