SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Design a Better SQL Server Pricing Model

By Andy Warren,

Today we have a guest editorial from Andy Warren as Steve is out of town.

It’s always been fun, or perhaps frustrating, to figure out what licensing model to use for SQL Server. Almost everyone opts for per core licensing because client access licenses (CAL) rarely fit and are one more thing to manage. DBA’s prefer the Enterprise Edition (EE) because it has more features/fewer limitations; businesses prefer the Standard Edition due to the lower cost, at least until they finally can’t avoid having to move to EE for a feature or to remove a limitation.

It gets more complicated. If you use EE in production, you need it downhill – that is, in your QA and Development environments. If not, you end up in a situation where you can’t test/confirm/use your code except in Production. Then there is the licensing cost itself that you negotiate, typically with big discounts if you up the count of licensed cores, and/or, in particular, the count of EE cores (and all of that means the list price has to be high so they can give the CIO a volume discount). Virtualization adds another layer. Licensing is just complicated. I think the only reason it survives is that once you have picked editions and negotiated prices , your effort is mostly tweaking the instance count and writing the check to Microsoft once a year.

Over the years I’ve heard people ask to have just a single edition. Others want the option to unbundle SSIS and SSRS. Still others request option to add only one EE feature (usually partitioning or online index rebuilds). I’m sure there are more. Just those three show the range of thinking. One group wants to remove the environmental complexity, the others want to manage costs most granularly. How do you make them all happy and still make money?

Should it be based on features, with more ala carte options? Unlimited use (as we have now) or metered usage - maybe per core with a factor related to the performance of the core? Or actual core usage? Transactions? Rows? Should the number of users matter, or the hardware it runs on, or whether it’s physical or virtual? Thinking about the Microsoft perspective it’s tough to design a licensing model that gives us options, drives revenue, and doesn’t require periodic adjustments for things like the performance of CPU’s or the uptick in virtualization.

So what would you change? Here’s my list:

  • We should only pay for Production instances (plus any readable secondaries)
  • One edition – Enterprise, licensed per physical CPU instead of cores
  • Unbundle SSIS and SSRS (perhaps SSAS too?)

Costs per license would go up, total licenses would go down. License audits would be easy. We’d pay for capability (CPU) instead of packaging (core).

I imagine by now a few of you have already clicked on the discuss link to point out the flaws in my plan. For those of you that are still here, can you think of a better model, one that would work for all of us and Microsoft too? Spending a few minutes thinking about what you see wrong, how you would fix it, and the implications of those changes is time well spent – you might decide the current model isn’t as bad as you thought!

Total article views: 151 | Views in the last 30 days: 1
Related Articles

SQL Server 2012: Creative Thinking for a Creative New Licensing Model

It seems inevitable that many customers will end up paying more to get the same features they have t...


SSIS Licensing Question



Which licensing model I am using ?

Which licensing model my SQL 2005 server is using ?


Give us all the features

The mix of hardware and feature limits in SQL Server varies by edition. Steve Jones thinks it should...


Reporting Services Licensing

Licensing models can sometimes make database modeling seem trivial. Per processor or per seat? S...