As SQL Server 2022 gets closer to GA status sometime during CY 2022, I have an “ask” for the decision makers at Microsoft. These are the people who do the final analysis and actually decide what the hardware-based license limits will be for SQL Server 2022 Standard Edition. My ask is that the SQL Server 2022 Standard Edition licensing limits be raised for SQL Server 2022.
SQL Server 2022 Standard Edition Licensing Limits
I think that the memory limit should be raised from 128GB to 256GB, and the core license limit should be raised from 24 cores to 32 cores. This post will explain my reasoning for this.
SQL Server 2019 Standard Edition License Limits
SQL Server 2019 Standard Edition has a 128GB limit (per instance) for the Database Engine, plus an additional 32GB per database for in-memory OLTP, with an additional 32GB per instance for Columnstore index usage. These license limits were the same for SQL Server 2017 and for SQL Server 2016 with Service Pack 1.
SQL Server 2019 Standard Edition is also limited to the lesser of four sockets or 24 physical cores on non-virtualized instances. On virtualized instances, it is limited to the lesser of four sockets or 24 virtual cores (which may map to logical or physical cores on the host).
SQL Server Standard Edition Licensing History
These Standard Edition license limits have slowly risen over the years but have stagnated for several versions now. The regular memory limit was last raised for SQL Server 2014, while the core limit was last raised for SQL Server 2016.
SQL Server 2008
SQL Server 2008 Standard Edition was limited to four sockets but could use the operating system limit for RAM. Fortunately, SQL Server 2008 was still using processor licensing, so there were no core-based license limits.
SQL Server 2008 R2
SQL Server 2008 R2 Standard Edition was also limited to four sockets but was now limited to 64GB of RAM (per instance). Happily, SQL Server 2008 R2 still used processor licensing, so there were no core-based license limits.
SQL Server 2012
SQL Server 2012 Standard Edition was also limited to 64GB of RAM (per instance). It was also limited to the lesser of four sockets or 16 physical cores.
This was the first version of SQL Server that had core-based licensing. At the time, this was not a popular change… But in the words of Darth Vader, “I am altering the deal. Pray I don’t alter it any further.”
SQL Server 2014
Microsoft raised the memory limit for SQL Server 2014 from 64GB to 128GB per instance. This was a very welcome increase! SQL Server 2014 Standard Edition was limited to 128GB of RAM (per instance). It was still limited to the lesser of four sockets or 16 physical cores.
SQL Server 2016
Microsoft raised the core limit for SQL Server 2016 from 16 cores to 24 cores. SQL Server 2016 RTM Standard Edition was still limited to 128GB of RAM (per instance). It was also limited to the lesser of four sockets or 24 physical cores. This core limit increase was a welcome improvement!
SQL Server 2016 Standard Edition SP1 also had an additional indirect memory limit increase if you used columnstore indexes or in-memory OLTP. You were allowed to use an additional 32GB per database for in-memory OLTP, and an additional 32GB per instance for columnstore index usage.
SQL Server 2017
There were no license limit increases for SQL Server 2017 Standard Edition. No soup for you!
SQL Server 2019
There were also no license limit increases for SQL Server 2019 Standard Edition. This means we haven’t had a core license limit increase for SQL Server Standard Edition since June 2016. We have not had a memory license limit increase since June 2014 (not counting the Columnstore or in-memory OLTP changes in SQL Server 2016 SP1).
Hardware Advances Since 2014
Processor core and memory density have changed quite a bit since mid-2014. Here is a brief history lesson.
SQL Server 2014
When SQL Server 2014 was released in June 2014, 22nm Intel Ivy Bridge E7 processors for four-socket servers had a maximum of 15 physical cores. More common 22nm Intel Ivy Bridge E5 processors for two-socket servers had a maximum of 12 physical cores each. This meant that SQL Server 2014 Standard Edition could run on any existing Intel processor on one socket and use all of the cores.
You could also run SQL Server 2014 Standard Edition with two, eight-core Intel Xeon E5-2667 v2 processors in a two-socket server and use all the cores. Running lower core count, frequency-optimized processors is a very common strategy for SQL Server. It can give you better single-threaded performance and reduce your SQL Server license costs. I have more guidance here:
- Choosing a Processor for SQL Server
- Recommended AMD Processors for SQL Server
- Recommended Intel Processors for SQL Server
A two-socket server that supported this processor family, such as a Dell PowerEdge R720 could have up to 768GB of RAM.
SQL Server 2016
When SQL Server 2016 was released in June 2016, 14nm Intel Broadwell E7 processors had a maximum of 24 physical cores, which meant that you could hit the SQL Server 2016 core license limit on one socket. The more affordable 14nm Intel Broadwell E5 processors for two-socket servers had a maximum of 22 physical cores.
It was also easy to exceed the SQL Server 2016 core license limit with many, lower core count SKUs on a two-socket server or on a VM. This was a more common scenario that I see quite frequently in real life.
A two-socket server that supported this processor family, such as a Dell PowerEdge R730 could have up to 1.5TB of RAM.
SQL Server 2017
When SQL Server 2017 was released in September 2017, 14nm Intel Skylake-SP processors had a maximum of 28 physical cores, which exceeds the 24-core license limit in one socket. First generation AMD EPYC “Naples” processors had a maximum of 32 cores, so they had the same problem.
SQL Server 2019
When SQL Server 2019 was released in November 2019, 14nm Intel Cascade Lake-SP processors still had a maximum of 28 physical cores. Second generation 7nm AMD EPYC “Rome” processors were released in August 2019. They have a maximum of 64 physical cores.
SQL Server 2022
By the time SQL Server 2022 is released (in CY 2022), we will have two new major processor family releases. AMD will have released their fourth generation 5nm AMD EPYC “Genoa” processors, with a maximum of 96 cores. Intel will also have released their 7nm Intel Sapphire Rapids-SP processors with a maximum of 56 to 60 cores.
In 2014, new server processors maxed out at 16 physical cores. In 2016, new server processors maxed out at 24 physical cores. During this period, Microsoft SQL Server Standard Edition could use all of the cores of one top of the line CPU. It could also use all of the cores of two mid-range processor SKUs.
In 2017, things changed. Intel had 28 core Xeon CPUs while AMD had 32 core EPYC CPUs. SQL Server 2017 kept the core license limit at 24 physical cores. This meant you had to be more careful about your processor selection and VM sizing.
By 2019, the situation had gotten worse. Intel had 28 core Xeon CPUs while AMD now had 64 core EPYC CPUs. SQL Server 2019 kept the core license limit at 24 physical cores. This meant you had to be even more careful about your processor selection and VM sizing.
So, what will happen in 2022-2023? Well, we know that both Intel and AMD will have even higher core count processors (with up to 128 physical cores). Will Microsoft raise the core license limit?
These hardware advances mean that there is a good argument that the core license limit should be increased to a higher number, just to reflect reality.
If Microsoft increased the core limit to 32, you would be able to use a two-socket server with two modern mid-range Intel or AMD processors. You would also be able to use a one-socket server with a 32-core processor. Having a higher core license limit would let you have a larger VM.
I also believe that the per instance memory limit should raised to a higher value. My suggestion would be to go to 256GB, which would double the current limit. Server-class DDR4 memory prices have gone down to about $6.00/GB for 32GB DIMMs, so it is feasible and affordable to purchase more RAM than people might have used in the past.
Think about this. If you had a VM with 24 vCPUs and 192GB of RAM, the SQL Server 2019 Standard Edition core license cost would be about $43K, while the cost of the memory would be about $1,200.00.
SQL Server 2022 Enterprise Edition Value Proposition
The obvious argument for why Microsoft would NOT raise these hardware license limits is that it might cause more people to use SQL Server 2022 Standard Edition rather than SQL Server 2022 Enterprise Edition, which could reduce Microsoft’s license revenues.
I think this change would actually encourage more people to finally upgrade from legacy versions of SQL Server Standard Edition to SQL Server 2022 Standard Edition. Being able to use higher core count processors and more memory would be an attractive combination which would increase revenues from SQL Server 2022 Standard Edition.
Justifying Enterprise Edition
Microsoft could (and really should) do a better job of demonstrating the value of SQL Server 2022 Enterprise Edition for performance, scalability, and useful Enterprise-only features. They could use KB articles, whitepapers, and blog posts to discuss the low-level optimizations that are in Enterprise Edition but not in Standard Edition. Putting all of this information together would be extremely valuable!
Doing a good job of explaining the value of Enterprise Edition would protect Enterprise Edition sales, and actually encourage more people to do Edition upgrades in the future. I have done some work in this area, such as this article:
For example, running a common benchmark like DBHammer on SQL Server 2022 Standard Edition, and then doing an Edition Upgrade and re-running the benchmark on the exact same system would be a pretty simple way to confirm performance increases. This could be extended by making easy configuration or database/code changes to fully leverage Enterprise Edition and re-running the benchmark.
Small Workload Argument
Every time I write a post like this, I get feedback about how people are happily running SQL Server Standard Edition on very small servers or VMs. For example, “All of my VMs have four vCPUs and 16GB of RAM and I don’t have any problems”. If that is the case, then good for you!
Unfortunately, many organizations are running SQL Server Standard Edition with larger workloads that have grown over time. They were fine several years ago, but their data volumes and concurrent workloads have grown to the point where they are under sustained memory or CPU pressure that is causing performance issues.
As a consultant, this is great! I have a whole collection of techniques to help alleviate memory and CPU pressure and improve performance. This gives me lots of ways to “save the day” and give a SQL Server Standard instance more breathing room for growth. But this doesn’t always work, or work forever.
You may not have the freedom to do certain types of configuration or workload tuning. At some point, there are diminishing returns from your tuning efforts, no matter how good you are. Not every organization has the ability or desire to upgrade to Enterprise Edition (even if they should).
I don’t have any illusions that Microsoft will just do what I ask here. They will do what they want, based on their internal priorities and goals. But SQL Server doesn’t exist in a vacuum. Things like hardware license limits should change over time to reflect hardware advances. Microsoft has a previous track record of raising these limits in the past. For some reason, they stopped doing this after 2016.
SQL Server 2022 Standard Edition Licensing Limits
I really do hope Microsoft raises the SQL Server 2022 Standard Edition licensing limits in order to help create an even more compelling upgrade story. What do you think? Is 128GB of RAM and 24 cores enough for SQL Server 2022 Standard Edition?
BTW, I think that SQL Server 2022 is going to be a great release. I have some related posts here:
If you have any questions about this post, please ask me here in the comments or on Twitter. I am pretty active on Twitter as GlennAlanBerry. Thanks for reading!