Sometime in late 2013 or early 2014, Microsoft will officially release SQL Server 2014. Based on publicly available information and rumors, it seems pretty likely that Windows Server 2012 R2 will also be officially released during that same time frame, probably somewhat sooner than SQL Server 2014. Related to this is the upcoming release (during Q3 of 2013), of the Intel Xeon E5-2600 v2 series of processors, also known as Ivy Bridge-EP, along with the scheduled release of the Intel Xeon E7-4800 v2 series of processors (Ivy Bridge-EX) in Q1 of 2014. You may be wondering what these have to do with each other and what they have to do with Microsoft licensing, so let me explain.
Windows Server 2012 R2 Standard Edition
Currently, Windows Server 2012 Standard Edition has an operating system license limit of 4TB for RAM, which is a huge improvement over the 32GB RAM limit for Windows Server 2008 R2 Standard Edition. While 4TB of RAM may seem like a very generous amount (which it is), we will soon have a problem when Intel officially releases the Xeon E7-4800 v2 processor series. It turns out that the Xeon E7 v2 family (which includes the E7-2800 v2, E7-4800 v2, and E7-8800 v2 series) has tripled the maximum memory capacity of the current Intel Xeon E7 family. This means that a commodity, four-socket server will support 6TB of RAM when you use 32GB DDR ECC DIMMs. Based on recent price history, it seems pretty likely that 32GB DIMMs will be pretty close to the same cost/GB as 16GB DIMMs by early 2014. This means that Microsoft really needs to raise the operating system RAM limit for Windows Server 2012 R2 to something higher than 4TB. My suggestion would be to raise the RAM limit to 24TB, so that a 16-socket server, fully populated with 32GB DIMMs, would be able to use the entire amount of available RAM.
SQL Server 2014 Standard Edition
Currently, SQL Server 2012 Standard Edition (and Business Intelligence Edition) can only use 64GB of RAM for the Database Engine. SQL Server 2012 Standard Edition is also limited to using 64GB of RAM for SQL Server Analysis Services (SSAS). Microsoft introduced this artificially low RAM limit in SQL Server 2008 R2 Standard Edition, and Microsoft left it in place for SQL Server 2012 Standard Edition. This RAM limit means that Microsoft is forcing you to use less than $800.00 worth of RAM for a Standard Edition instance, which is ridiculous in 2013/2014.
Microsoft could decide to make SQL Server 2014 Standard Edition licensing more consistent with Windows Server 2012 Standard Edition and Windows Server 2012 R2 Standard Edition licensing by abolishing the RAM limit completely. After all, there are plenty of compelling and valuable features in SQL Server 2012 Enterprise Edition that make it well worth the extra licensing costs compared to Standard Edition. Eliminating this old-fashioned, artificial RAM limit would not hurt Enterprise Edition sales, and it could actually help them in the end. I can see a scenario where someone can buy a powerful new server with lots of RAM initially running on SQL Server 2014 Standard Edition. Then, as their needs and budget change, they could simply do an Edition upgrade to Enterprise Edition to instantly get better performance and scalability and to use the Enterprise Edition-only features that they need.
If eliminating the RAM limit completely is too radical a change, Microsoft should at least raise the limit to something like 128GB or 256GB. Keep in mind that two-socket servers such as the Dell PowerEdge R720 and the HP ProLiant DL380p Gen 8 can have 384GB of RAM with 16GB DIMMs and 768GB with 32GB DIMMs. Even an entry-level, single-socket Dell PowerEdge R320 server can support 96GB of RAM, so a 64GB RAM limit is simply too low by modern standards.
Related to this is the current four-socket or 16 core (whichever is lower) limit for SQL Server 2012 Standard Edition. Current 32nm Intel Xeon E5-2600 series processors (Sandy Bridge-EP) can have up to eight physical cores each, so a two-socket machine will just max out the core limit. The 22nm Intel E5-2600 v2 series (Ivy Bridge-EP) will have up to twelve physical cores each, so a two-socket machine will be able to easily exceed the limit. AMD has had 16-core processors for quite some time that also work in two-socket servers. The Intel Xeon E7-2800 v2 series (Ivy Bridge-EX) will support up to 15 cores per processor, so a two-socket machine would also exceed the current core limit for Standard Edition. Microsoft should simply raise the license limit to four-sockets or 32 cores, whichever is lower. This would allow a customer to fully utilize any two-socket server, without using named instances.
Finally we have the issue of Database Mirroring being deprecated in SQL Server 2012, with no viable replacement being made available for SQL Server 2012 Standard Edition. I previously wrote about that subject here. Microsoft could pretty easily solve this issue by giving SQL Server 2014 Standard Edition limited support for Availability Group replicas, with just one synchronous replica being allowed. This would be consistent with how Database Mirroring is supported in SQL Server Standard Edition today.
If Microsoft Marketing is feeling particularly generous, they could also allow some limited support for the Buffer Pool Extension (BPE) feature in SQL Server 2014 Standard Edition, perhaps by limiting the size of the BPE file.
These simple licensing changes would greatly simplify the licensing story and would add some consistency between Windows Server Standard Edition licensing and SQL Server Standard Edition licensing. It would also give SQL Server 2014 Standard Edition customers a much better high-availability story in the product.
These changes would also help drive upgrades to SQL Server 2014, especially as SQL Server 2008 and 2008 R2 fall out of mainstream support on July 8, 2014. It would encourage customers to buy new, two-socket servers, running Windows Server 2012 R2 that can fully utilize the hardware limits of the server, giving them a clear, logical upgrade path to Enterprise Edition in the future.
4 thoughts on “Common Sense Licensing Changes for SQL Server 2014 Standard Edition”
I hope someone at Microsoft listens to your recommendations.
Seem ridiculous that I can buy a $20k server that needs $200k in software licenses.
I agree, Engraving one's name on the pen is 10 times costlier than the pen itself, ridiculous!
My company started running into SQL's "artificial" resource limits and crippled features around when 2012 released. At the time we decided to research implementing MySQL – actually MariaDB – (even though i originally cringed at the mere thought).
The research/testing took 3 months – we are now also running a vastly improved server stack: 2 servers with 32-cores and 512GB RAM.
We would have had to upgrade 4 x CPU Std Licenses (on one server) for the newly required 8xCPU license… Needless to say, I saved the day by avoiding SEVERAL Ferrari-sized expenses to my server costs… ESPECIALLY when the awesome new hardware only cost as much as a Mercedes.
I mean, can anyone other than Finance and Big Healthcare afford enterprise (CPU) licenses?
In 2011-2012 it was merely a tiny bit painful switching; these days (Mid-2014) the featureset of MariaDB can run circles around SQL Standard, and even beats the shit out of it when it comes to some features – especially Spatial/Geo. And the latest redundancy and hot-backup features have recently gotten SO MUCH BETTER THAN ENTERPRISE EDITION. Not quite as easy as MSSQL, but SO MUCH more reliability could be achieved with a couple weeks planning + execution – did I mention you could buy matching Ferrari's when you're done? ;)
Glenn, as a Microsoft employee for nearly a decade, I never had to worry about licensing. Every installation was a no-brainer: Windows Server 2012 R2 Datacenter + SQL Server 2014 Enterprise. I'd paid a bit of attention to the complaints from customers & MVPs. I was sympathetic. Yet over the years thought surely things would improve. However, now that I'm out in the field, I'm not only feeling the pain, but also I am amazed at the complexity. How is it that common sense proposals such as yours aren't embraced? Doing so might serve Microsoft well.
Comments are closed.