As you might be aware, SQL Server 2012 Standard Edition has some hardware-related licensing limits that I think should be adjusted in light of the capabilities of modern, commodity server hardware.
As a DBA and consultant, I would like to see everyone running SQL Server 2012 Enterprise Edition. It has many, many truly compelling features that make it absolutely worth the extra licensing cost compared to SQL Server 2012 Standard Edition. Despite this, I recognize that some organizations simply cannot afford these extra licensing costs (even though it is still far more affordable than Oracle licensing).
The first SQL Server 2012 Standard Edition licensing limit is that you are restricted to 64GB of RAM for the Database Engine and 64GB of RAM for SSAS and SSRS. Even if your database server has a much higher amount of RAM than 64GB, it will only be able to use 64GB of RAM for each of these services.
I think that is is a ridiculously low RAM limit, given the fact that DDR3 ECC RAM for servers is currently priced at around $10-$15/GB for 16GB DIMMs. Microsoft is essentially limiting you to using about $1000.00 of RAM if you are using SQL Server 2012 Standard Edition.
Modern, two-socket servers have 24 memory slots, so they can hold 384GB of RAM with these affordable 16GB DIMMs. Even though you are limited to 64GB of RAM per service per instance, you should strongly consider getting a slightly larger amount, such as 72GB or 96GB, so that you can set your Max Server Memory setting to 65536 (which would be 64GB), and still leave plenty of RAM for the operating system.
This 64GB RAM limit did not exist for SQL Server 2008 Standard Edition, which could use up to the OS limit for RAM. It was first introduced in SQL Server 2008 R2 Standard Edition, and was not changed for SQL Server 2012 Standard Edition. That was a mistake, in my opinion, designed to drive more Enterprise Edition sales.
Windows Server 2012 Standard Edition can use up to 4TB of RAM (unlike Windows Server 2008 R2 Standard Edition, which was limited to 32GB of RAM), so there is even more precedent for not placing artificially low RAM limits on the Standard Editions of Microsoft Server products.
The second hardware-related licensing limit for SQL Server 2012 Standard Edition is that you are limited to the lesser of 16 physical processor cores or four processor sockets, whichever is less. I don’t really have a problem with the four processor socket limit, but I do think that a 16 physical processor core limit is simply too low. A two-socket, AMD Opteron 6200 or 6300 series based system could have 32 physical cores, while a two-socket Intel Xeon E7-2800 series based system could have 20 physical cores.
Of course, you really should not be using any of those processor families for SQL Server 2012 usage, since the Intel Xeon E5-2600 series is far superior for single-threaded performance and would also have a lower core-based licensing cost. It is also likely that the upcoming Intel Xeon E5-2600 v2 series (Ivy Bridge-EP) could have up to ten physical cores per processor, which would put a two-socket server over the 16 physical core limit.
I would really like to see Microsoft eliminate both the RAM limit and the physical core count limit for SQL Server 2012 Standard Edition. The features and advantages of SQL Server 2012 Enterprise Edition are valuable enough to convince people to buy Enterprise Edition when it is appropriate without these artificially low license limits. Microsoft could support this notion by doing a better job of explaining and selling the benefits of Enterprise Edition, with some blog posts and whitepapers.
I would love to hear your thoughts and opinions on this!
Glenn Berry's SQL Server Performance 
Totally agree with you on this and not only because it “just not make sense”(except for the Sales team probably), but because Microsoft has the great chance to be extremely aggressive and market the product even better and to an even wider audience if those 2 hardware limitations were not there. I would be really interested to watch a video for example, on how the Sales team and all teams involved in the licensing and its limitations actually make their decisions.
Regardless of whether Microsoft would ever consider changing these licensing limits for Standard Edition, if a few PMs and developers would write some blog posts where they explain some of the differences and advantages that are in Enterprise Edition, it would be very helpful to everyone who tries to make the case for Enterprise Edition. Even better would a nice whitepaper from the SQLCAT team where they did some benchmarks comparing Standard Edition to Enterprise Edition, on the exact same hardware and storage subsystem.
I don’t know. I’ve worked for a few organizations that couldn’t afford Enterprise edition… they couldn’t afford “commodity” servers with anything close to 64GB of RAM either. For these orgs, virtualization is the way to eek out the most value from a large server – and I’ll admit I mean “large” in the 24-32GB RAM sense. These places mainly have other business or altruistic goals that come before technology – that data may be their lifeblood for grant purposes and donor management, but technology is the common tool to achieve that greater mission.
So while I’ve beleaguered the point, the limitation isn’t going to be an issue for many people I know. Even if only because they’re probably still on SQL 2005. But they’ll never have the capacity to come close to that limit, and if they did, that money would be earmarked for other purposes.
Many organizations that truly can’t afford commodity servers are probably using Excel or Access or SQL Server Express Edition for their database needs, probably on an older desktop system literally on someone’s desk. They probably don’t have any I.T. staff, much less a DBA. They have a whole different set of problems to worry about.
I don’t have a problem with these limits, though I’ve said before I think the limits should be scale related. Don’t alter the feature sets for editions, just set hardware limits.
Is 16 cores too small? I’m not sure. Hard to know these days. I still think most databases people run are < 100GB, if not < 10GB. That's in numbers, so is 16 cores and 64GB enough? Probably.
I don't agree that companies that can't afford commodity servers are running Access or Express. There are lots of companies that don't see a value in spending the 5x cost for EE over SE when they are running web apps, internal apps, that just don't need huge hardware for things to work at an acceptable level.
I’m with you, Steve. If EE was 2X or 2.5X it would be a much easier sell. I am right now trying to convince my management that we need at least on EE instance and all they see is the $$$$$$$$ and can’t easily see how the additional features warrant the cost.
My argument was/is that many smaller organizations who literally cannot afford to buy a few commodity servers to run their business on probably cannot afford SQL Server Standard Edition licenses either.
Obviously, there are many somewhat larger organizations who can afford to buy or lease a few commodity servers, who can also afford SQL Server Standard Edition. They don’t have huge workloads, they don’t have huge databases, and they probably are not 24x7x365 shops either. Many of them are probably just fine with the existing license limits for SQL Server 2012 Standard Edition.
I’m the one trying to make the case that there are at least some even larger organizations who could take advantage of having more than 64GB of RAM in a database server running Standard Edition, but they don’t think they need or can afford Enterprise Edition.
My other point is that Enterprise Edition has enough value that there is no need for these artificially low license limits that were not present in SQL Server 2008 Standard Edition.
Our company probably falls into this third criteria that we can afford but really do not need the great features of EE at this point but we could really use the higher memory and cpu limits with Standard Edition.
This is very helpful article and I have forwarded it to our decision makers who have decided to go Standard on 2012 where ever we were EE on 2008 R2 if extra features are not required because of huge cost savings.
You also have the option of the “Web Edition”, which is a fraction of the price of “Standard Edition” with most of the functionality and similar limits (4 socket / 64GB).
However your app can’t be “line of business” if you are using that version.
I also don’t think that enterprise edition has any compelling selling points for MOST companies
They most mentioned extras are..
—-Resource governor (Useful but good coding, archiving and security make it redundant)
—-Unlimited RAM (Fair enough, but I have 500GB db’s running very well on 16GB RAM)
—-Always on (Brent Ozar spotted some issues with this and it also has punitive licencing costs – log shipping is actually a better option if there is data corruption )
Licensing costs always elicit an negative emotional response from stakeholders- They see it as dead money compared to buying a physical object such as a server, therefore they scrutinize these costs a lot more
My justification was data compression, enabling us to cram 85GB compressed from 250GB into 128GB RAM and enjoy lightening data access speeds, coupled with online rebuild of any and all indexes in support of a 24×7 99.997 uptime requirement. We needed 4000+ IOPS and no reasonably priced subsystem could support that, hence RAM + EE was an easy decision $$$ wise vs. SAN at hundreds of K and we managed this on a 12-core box, dropped from 16. Hence we get 25000 transactions/second now and near zero IO queue depth. As usual, “it depends”.
Sadly, another site I’ve just inherited doesn’t have the budget for EE, is on 2005, needs to get to 2012, needs more RAM as they are constantly having memory issues, are on 3 separate boxes, have linked-server query drag, 16GB/machine or 16 cores. Standard is all that’s currently available. I’d SORELY like to see the 64GB RAM limit raised. Even if MS doubles it, that’s a huge benefit to SMB’s… Aggregations/Stats for a client over their lifetime is a current requirement that, admittedly, needs optimization with cacheing, so without that optimization, to have the 80GB DB in memory in Standard wished-for-128GB vs. being constantly paged with even 64GB, would be a vast improvement visible to the end customer.
Thanks, Glenn for clearly enumerating the license issues.
I agree with the RAM and CPU restrictions being put to sleep. Leave Enterprise licenses to the SQL installations that can charge their customers for the 99.999% uptime they require. After all, ANY hardware is designed to be used; ask your employer if he minds paying you 100% salary for 50% productivity…
I think, but I was told things have changed, that Microsoft is one of the biggest pushovers in the industry. They still practice the good-old “say no 3 times [or more] and then make your customers happy no matter what” approach; a couple of petitions would do the trick. Who wants to write it?
Just something for sharing and also would like to learn insight: We have Windows 2012 running SQL Server 2012 SP1. We have 128GB RAM installed and didn’t expect SQL Server uses more than 64G. But it turned out it in fact used up to 120GB. We also have SQL Server 2008 R2 that is able to take over 90GB RAM. I wondered if those are un-documented features. Any one have insight into it?