SQL Server: Standard vs Enterprise Edition

Do you need SQL Server Enterprise Edition? Maybe. Maybe not. This blog post will help you figure out if you can make the move from SQL Server Enterprise Edition to SQL Server Standard.

Lately, we’ve been finding more and more folks who can answer that probably not. I’ve lost track of the number of clients we’ve helped downgrade from SQL Server Enterprise to SQL Server Standard during our SQL Server Upgrades, take advantage of new features, and fairly dramatically reduce their costs. I just hosted a webinar today with SIOS Technologies and David Bermingham talking about that. I’ll share the video from MSSQLTIPS here tomorrow when we have the link, and once I get the list of questions asked we didn’t get to – I’ll answer them here in a post tomorrow.

For now, a brief post where I’ll cover some things to think about, some reasons to consider downgrading to standard, some reasons to stay Enterprise. Tomorrow I’ll share the link to the webinar and talk a bit more about achieving HA with SQL Server standard in the cloud.

The answers here are not one size fits all. Some folks need to stay on SQL Server enterprise. Some folks should be on the fast track to “downgrade” from SQL Server Enterprise to SQL Server Standard.

Why Downgrade from Enterprise to Standard Edition in SQL Server?

Saving $10,000 for each 2 core pack is a good starter reason. On an 8 core server – that’s $40,000 reasons. And that’s without software assurance (which is a whole other topic for another post – navigating Software Assurance and licensing)

It’s not all about money. Let me phrase it this way – “Why not?” Sure there are some reasons to stay on Enterprise (See below), but many of the reasons we used to give without much thought aren’t good reasons anymore. Here are just some of the things we get with SQL Server standard nowadays in SQL Server 2019:

• 128GB RAM – up from 64GB in SQL Server 2012 and below.
• 24 Cores (or 4 sockets, whichever is lower) – Up from 16 cores in SQL Server 2014
• Two node (single instance) Failover Cluster for High Availability (more on this tomorrow – including how we do that with many clients in the clouds)
• Availability Groups (with some limitations, starting in SQL Server 2016)
• Compression (Data since 2016SP1 and Backups a lot longer)
• Encryption (Backup, TDE, Always Encrypted) – TDE/Always Encrypted are new in SQL Server 2019
• Partitioning
• Query Store
• All security features (Always Encrypted, Server and DB audit, EKM, Backup encryption, Dynamic data masking, etc.)

There’s more here at the edition feature matrix for SQL Server 2019. You can click the links to see the evolution from 2017/2017/2014 and earlier.

In short – if your workload can handle 128GB of RAM or less, 24 cores or less – and you don’t need the few enterprise features described below – perhaps you should really be considering SQL Server Standard. It may even be easier to test this out than you realize with VM and cloud-based environments!

With fairly little effort, we saved a few clients about $60,000 – $80,000 per year respectively on their AWS licensing by bringing them from Availability Groups in Enterprise Edition to Failover Cluster Instances in SQL Server Standard.

Do I Need SQL Server Enterprise Edition?

If you truly need some of the “Performance” minded features that are a feature of Enterprise Edition, it makes sense to stay there. If you need more than 128GB of RAM or more than 24 cores, it also does.

Some of the things you miss (that link above will show the complete list) when going to Standard:

• Online Index Rebuilds (but we don’t think you should be rebuilding your indexes as often as you probably do, and we don’t think you should be rebuilding when the fragmentation is as low as you are probably rebuilding at)
• Resource Governor
• Some of the advanced engine features that give Enterprise Edition better scale (like read-ahead reads and other optimizations at the storage tier – though with a well-tuned database on solid IO – for a DB environment that fits in 128GB of RAM – this may not be as big of a deal as you fear)
• Availability Groups with readable secondaries (though – those require you to know license TWO enterprise edition SQL Server instances. If you 100% need this feature and all it brings – then you need Enterprise. But – can you get by with a nightly restore? Or, if you need more data recency – can a Transactional Replication work? It’s not as scary as it sounds – and you can replicate to a Standard Edition secondary, and you can even add indexes for reporting only on the subscriber – unlike an AG)
• Multi-Node FCIs
• See the above list for more.

Sure. You are giving a few things up with Standard edition. And some folks truly need those difference makers. But in SQL Server 2017, one of those difference makers was “TDE is needed for the auditors” – that’s gone now. In SQL Server 2016 RTM, one of the difference makers was “Compression isn’t there” – that’s been gone as an excuse since SQL Server 2016 SP1

So What Should You Do?

I’d probably have a flow chart that sort of starts with:

1. Do you need more than 128GB of RAM? (much more – I don’t mean 192 or 144GB – that may still be enough to see if you can do some tuning and optimization)
2. If No – Do you need more than 24 cores?
3. If No – do you require a read-only secondary feature in an AG or the 3 node HA/DR in one solution?
4. If No – Do you really need online index rebuilds (and if the answer is yes – are you rebuilding all the indexes every week whether they need it or not? If not, that’s not a good enough excuse)

If you kept getting No answers – you should see what happens on SQL Server Standard in a test environment. If you are at 144 or 192GB of RAM – see what happens when you lower SQL’s max memory more – or lower the VM you are running on to 128GB – or move your cloud infrastructure to a size that is more appropriate for standard – what happened? How did the tests go?

And don’t forget – with the savings – you can spend some more time tuning your DB, you can spend some more budget thinking about scale-out architecture, you can think about using things like FCI + Log Shipping to give HA + DR and stay on standard and get your “included HA pair and DR third SQL Server.”

More tomorrow when I hopefully share the link to the recording and some answers to questions. The webinar today talked a bit more about FCIs in SQL Server standard and utilizing block-level replication tools; SIOS Datakeeper is the tool we prefer, though there are others.

What do you think? Can you save your company money one time? Or can you cut your cloud bill in half on the SQL Server side? I’ve seen folks do it, and it always makes me wish we put a “Percentage of license savings” bonus clause in our contracts! Consider making the move from SQL Server Enterprise to SQL Server standard today. We can help for sure, just reach out if it’s needed.

Drop me a note through the contact forms on the site if you have a quick question about your environment. We’re pretty busy, and I can’t give you a full architecture and migration plan through e-mail, but I can at least point you in the right direction and get you started down a path!