The Marginalization of SQL Server Standard Edition

I’ve complained in the past about how SQL Server 2008 R2 and SQL Server 2012 artificially constrained SQL Server Standard Edition to a mere 64 GB of RAM (and a total of 16 cores). SQL Server 2014 happily raises that artificial constraint to 128GB of RAM.

But I maintain that 128GB is still too greedy on Microsoft’s part.

Put another way, since Microsoft has switched SQL Server licensing to a per core model (which is only fair given the state of the processor market), an organization that decides to license a SQL Server 2014 Standard Edition instance with 16 cores will have to pay to license all of those cores, but only be able to power each of those cores with a paltry 8GB of RAM.

A Better Approach to Licensing: License Memory per Core

In my mind, if Microsoft is going to charge per core, then Standard Edition memory limits should be based on the number of cores present. Under such an approach, if each core came with support for say 24-32GB of RAM, then a minimal 4-core license deploymenmt would come with support for 96-128GB of RAMm and a 16-core server would come with support for 384–512GB of RAM. (Personally, I think the 16-core limit for Standard Edition is just fine—larger machines almost invariably end up being more 'enterprise-y' in terms of usage.)

Granted, such an approach to licensing memory would tend to complicate things a bit (licensing is already confusing enough as is). But I can’t help but think that such an approach wouldn’t end up making Standard Edition feel, again, like a full-fledged citizen and make licensing it feel a bit more fair.

The problem, though, is that I’m not sure that Microsoft is interested in trying to be fair.

A Question of Revenue

If we take an overly-simplified look at licensing and assume that Standard Edition licenses cost roughly $3k per 2-core pack, and SQL Server Enterprise Edition weighs in at roughly $18K per each 2-core pack, then it’s not too hard to see which edition Microsoft would want to sell. (I also continue to maintain that the benefits that Enterprise Edition brings to the table are well worth the price increase.)

That math aside, the notion I can’t seem to shake is how Microsoft seems to be bent on marginalizing Standard Edition—both in the sense of the artificial constraints placed upon how much memory it can use, and in terms of what seems to be a shift in focus on the role of Standard Edition from Microsoft. Take, for example, the following description pulled from Microsoft’s website describing the role of SQL Server Standard Edition:

SQL Server Standard provides core data management and business intelligence capabilities for non-critical workloads with minimal IT resources.

Assuming a server with dual-hexa-core processors, licensing such a server with Standard Edition would weigh in at the need for 6x2-core packs, or roughly $18K. Granted, that’s not enough to break the bank, but I’m pretty sure that many small-to-medium businesses might balk at the notion of paying around $10-15K for hardware and then $18K for licensing on what Microsoft defines as a "non-critical" workload—when that workload could, in fact, be a key component of the core of their business.

Put differently, Microsoft would be insane not to focus on Enterprise Edition. But, I also suspect that SQL Server didn’t battle its way to the No. 1 most-heavily used RDBMS solely because of Enterprise Edition sales. In fact, I’d wager that the bulk of Microsoft’s SQL Server customers are actually part of the "Global Fortune 1,000,000" running on a heavy degree of Standard Edition than they are Fortune 500 businesses running on Enterprise Edition. As such, I guess I continue to be just a bit confused and chagrinned at how Microsoft seemingly keeps on trying to marginalize SQL Server Standard Edition. 

Related: SQL Server 2012 Licensing Help

Discuss this Blog Entry 6

on Jul 17, 2014

Ignoring the issue whether it is a good pricing model - I don't quite buy the argument of 16 cores and 128GB is "8 GB per core." The RAM usage is presumably shared across the cores: database pages in memory that can be accessed by any query thread. When running a server dedicated to a single production database (the clients of my company's product), they need RAM related to the size of the database; but cores related to the number of user/report queries. The 64GB or 128GB is shared across all the cores, not partitioned out.

on Jul 17, 2014

Mark my words, unless they undo what they've done in SQL2014 licensing, they're shooting themselves in the foot.
My company has already started switching to Oracle because of the cost difference. The loss of potential Std. Edition sales will have a larger negative effect than higher sales in enterprise editions. They're heading the wrong direction.

on Jul 17, 2014

Wow, interesting to hear about your switch to Oracle. -- Jayleen, Editor

on Jul 17, 2014

I believe twilsion is correct

I'm having a bit of trouble on the switch from SQL to Oracle based on cost.

I worked at a company two years ago and we went from 2008 to Oracle10g. The DB was just under a TB with 40,000,000 updates daily. It took a team of 20 programmers 4 months to convert the code base. And 4 DBA's another 4 months to migrate and move the app.

That pays for a lot of Licencing!

Oracle did not perform better with less CPU (as the Oracles DBA's told us) In fact about 50 %slower. Yes we contacted some of the best consultants to look at it!

I've worked with SQL since 1990, and only two years on Oracle. Oracle DBAs cost more the SQL DBAs and SQL requires much less effort to maintain and tune. Think two Oracle DBAs for each SQL DBA.

A friend just went thru a People soft upgrade. He wanted to know why they recommenced almost twice as much hardware to run on Oracle as SQL .

Maybe I'm missing something. I just don't see the savings

This is

on Jul 31, 2014

Performance has nothing to do with Oracle, and everything to do with the actual code. I'm sorry to say this, but your team of 20 developers didn't do a very good job, likely because they didn't understand the differences between the platforms and weren't given enough time. Sadly this is rather common when porting code from SQL Server to Oracle. It needs to be rewritten.

Which is why switching from one database platform to another on the basis of costs savings really is ludicrous.

I'd argue against SQL Server being less effort and easier to tune, and you simply cannot make any kind of informed statement on the matter with only 2 years of Oracle experience. I've managed SQL Server and Oracle databases for 10 years, and neither of them cause me problems.

As for Peoplesoft, it was a purchased product by Oracle. Sadly it's still a mess, and doesn't follow many Oracle best practices. Not the database product's fault by any means.

on Jul 18, 2014

This is pushing us to virutalization, which with the newer versions of VMware is a viable option and most cost effective. Having physical clusters is no longer cost effective due to the licensing cost and the fact that in the majority of cases resources sit idle and/or unused. Licensing the host cores and laying instances/clusters on top is the way to go.

Please or Register to post comments.

What's Practical SQL Server?

Practical advice, insight, and help for core SQL Server considerations.


Michael K. Campbell

Michael K. Campbell is a contributing editor for SQL Server Pro and Dev Pro and is an ASPInsider. Michael is the president of OverAchiever Productions, a consultancy dedicated to technical evangelism...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×