March 24, 2011 at 9:35 pm
Comments posted to this topic are about the item What Differentiates Enterprise?
March 24, 2011 at 9:48 pm
Hi,
What a timely topic. Only yesterday I was reviewing licencing of SQL Server. I have many small clients (some of which only install SQL Server because our product requires it). A major issue of mine is to get these clients to upgrade (have clients still on SQL Standard 2000). All they see is that they have bought SQL Server (obviously several years ago) and now I am asking them to replace (not even upgrade) one working version with the new model for $5000+. Hard to get them to see the benefits (yes I tell them it faster etc) and to spend the money.
The databases (3 for each client) are from 100 MB to 20 GB (so not large with 5000000 rows in one of the tables). This table is also joined to other tables to return a report which can be quiet slow (30sec+) and partitioning of this table that SQL 2008 Enterprise allows would be fantastic for this as most of the queries only require information from the last few days/weeks.
I would really like to see a model where I could pay to run these small sites on a single or dual core and limited ram for a price that would entice my clients to upgrade.
SQL Express would nearly do the job for most of my small clients but I have found its performance is somehow "restricted" and does not return queried information as quickly as SQL Standard for whatever reason. Anyone got any comments on that issue?
Simplifying the licencing within a VM environment would also be appreciated.
Milton
March 25, 2011 at 1:04 am
Hi Milton,
Perhaps you should look into the feasibility of "hosting" the application yourself, Software As A Service(SAAS) in the Cloud using SQLAzure for example. This way you have the option to control the hardware environment specifications/performance across the board or specifically on a per client basis should you choose. Your clients can subscribe to a "level" of your service that is appropriate for them.
March 25, 2011 at 1:20 am
It is all a little arbitrary; log shipping was particularly silly since you could either write the scripts yourself or just copy them from an EE installation. Compression was also an odd one - think this might be more use to small customers than big ones, but it was (is?) an EE only feature.
I agree that a simple per-core model would be simpler - we are presently facing tradeoff between buying Datacenter Edition so we can run a bunch of VMs on the box, or individual licences for all of our smaller VMs e.g. SSRS only instances.
On this, it might also be an idea to licence SSRS, SSAS, etc. separately, though I realise this is proceeding down the Oracle path.
March 25, 2011 at 2:30 am
I disagree here. Licensing per core is all well and good, but you might well end up paying to license a feature you don't want and never use! I'd rather see some sort of system where, rather than have fixed "editions" of the product, you just pay for the bits you need.
March 25, 2011 at 4:01 am
Hmmm... I don't think this is going to resolve anything, is it?
My main gripe is one of chickens and eggs, for prototyping a months trial is not long enough to test and demonstrate features only available in the enterprise edition, so we learn to live without them.
When the business arguments for these features become fully apparent it can be at the expense of the project itself (why throw more money at this, it's useless).
So to my mind Microsoft are shooting themselves in the foot a little, certainly a full feature set on the basic edition linked to some kind of scalable licencing would make adoption of enterprise features far more likely in our organisation.
March 25, 2011 at 5:50 am
FYI - Compression is now available in Standard Edition in R2 - yay!
One thing that annoys me is that SSRS consumes a whole license if you put it on it's own box. I consider it a best practice to isolate SSRS from the core engine for performance reasons. I think licensing SSRS separately would make sense. Also, I have been burned many times where I install Standard and then 6 months later go to use some feature and it's not allowed because you are running Standard.
We are heavy users of async mirroring so we typically install Enterprise most of the time.
March 25, 2011 at 6:16 am
I think you gave the best answer to the general question right in your editorial...
"In my mind, I'd like to see SQL Server priced on scale, and not on features..."
What differentiates an Enterprise IS scale! Hence, it seems silly to arrange pricing and licensing any other way. This should be the case not only for SQL Server, but for all products that want to approach the market this way. As it is right now, we run into many clients who not only don't understand the differences between versions, but even those who do can't figure out why this is done as it is.
SQL Server is kind of unique in this way because, more than any other MS product, scale is highly important - but we are seeing Windows 7 cause a great deal of confusion in the marketplace due to these different versions. The same was true with Vista although thankfully, it had very low business market penetration.
Scale seems to me to be the most obvious factor in differentiating versions, especially in the case of any RDBMS. Unfortunately, I think the differing versions in other products (OS's, Office, etc.) is simply a gimmick - and its a gimmick we don't really need in the marketplace.
March 25, 2011 at 7:04 am
I think it would be in Microsoft's best interest to provide all the features and change the levels to limit on number of CPU or amount of memory. This would allow the skill level and pool of talent to grow around the product. If there are more people who know the product, Microsoft will sell more product. It becomes a feedback loop that will continue to grow.
March 25, 2011 at 7:24 am
paul.knibbs (3/25/2011)
I disagree here. Licensing per core is all well and good, but you might well end up paying to license a feature you don't want and never use! I'd rather see some sort of system where, rather than have fixed "editions" of the product, you just pay for the bits you need.
This then becomes fighting for any feature that's useful which I'm sure can be a very painful process. Right now the argument could be that clustering is needed and partition is very useful so by going to a higher edition we get both. If you had to pay for each feature you're more likely not to get partitioning because only clustering is really needed so management shoots down one.
March 25, 2011 at 7:25 am
Unfortunately these decisions are based on the coolness factor as seen by Marketing.
These are non-IT types that would increase the cost of cancer drugs to afford that new Mercedes they want.
The cooler the feature or the more likely it is to save you time or money, the more M$ Marketing wants you to pay for it.
Marketing runs the show on the price structures.
My favorite quote, "M$ does not really sell or market anything, we just tell everyone what the product costs and wait for the checks."
March 25, 2011 at 7:45 am
I like the idea of a scale system to distinguish the different editions but I'm thinking the scale of the organization rather than the hardware.
A company with 1 business unit and less than 100 employees may only need the standard edition with only the features an organization of that scale would need.
As the number of business units and employees increase so do the need for features.
Simple right... 😛
March 25, 2011 at 7:52 am
Being very much a SQL Server novice, take this with a grain of salt.
From what I've read here, it seems the consensus would be to license ALL features to all versions (except maybe Express,) and charge based on cores / sockets and RAM. To me, I think this might be the best way to do it. It would keep the features the same across all versions, making the jobs of Devs easier as the Dev edition would match up. If the Dev finds using a feature (say partitioned tables) improves the application, they know the clients will have it. If down the road it's found that the SQL Server is starved for resources, then the client could purchase a license to the next version, providing access to more of their hardware.
I think the biggest issue for doing this, would be for MS to write SQL to not use more than a set amount of RAM, or a set number of cores / sockets, as well as including a method to increase these numbers.
Jason A.
March 25, 2011 at 7:58 am
I agree 100%. There are several instances where we need features like partitioning, but don't need the raw CPU horsepower of more than 2 cpus (multiple cores though). So in this case, we're forced to look at something like Mysql. It seems like it would be easier to have Sql Server limit itself based on physical CPU count, and get rid of some of the other issues related to using the database for a web-based application (Sql Server Web Edition can be used, but only on the same server as the web site, or bump up to the more expensive per processor edition of Standard), what sense does that make from a management viewpoint/multi-tier application?
So in this case, not having the feature leads to $0 revenue for Microsoft because we can't justify the Enterprise pricing (in this case partitioning is not even available on Sql Azure yet, so we can't even look there), although we use and love Sql Server for everything else.
March 25, 2011 at 8:01 am
Y'all should just thank your lucky stars you don't have to deal with Oracle licensing.
Per processor licensing? Sure! Now we just have to define what a "processor" is -- yes, it depends which ones you use in your servers.
You want to monitor your expensive Enterprise-licensed database(s)? It's FREE (with the afore-mentioned Enterprise license)! Oh, you want to actually be notified when there's a problem? That's $5K/processor.
You want help tuning your DBs? $5K/processor
Compression? That's $11.5K/processor
As an example -- purely hypothetical -- on an AIX box with 8 POWER5 CPUs (it matters which model of POWER for licensing!), the $5K/processor price comes to $30K -- to send an email that tells you there's a problem. The compression price comes out to $69K for that server -- that's a lot of disk and CPU in today's market.
And this doesn't include annual maintenance.
I'm an admitted Oracle bigot, but there's a very good business reason that we have 13 SQL Server boxes.
Rich
p.s. The above pricing is list as of 03/25/2011 from http://shop.oracle.com
p.p.s. We're buying our first SS Enterprise license now, but only to use more than 2GB of RAM (good ol' SS2K).
Viewing 15 posts - 1 through 15 (of 34 total)
You must be logged in to reply to this topic. Login to reply