Design a Better SQL Server Pricing Model

  • Comments posted to this topic are about the item Design a Better SQL Server Pricing Model

  • I think that most will use a developers copy or msdn copy for all non-production copies of sql.

  • I'd like to be able to set the developer edition to mimic other editions in terms of features. The problem with having everything is that it is too easy to use something in an edition you are not planning to purchase for production. This is only related to licensing because sometimes places are pushed into a corner when someone on the development team accidentally uses a feature they shouldn't. This is similar to least privileges required in my opinion.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Being charged per core is a rip-off due to the decrease in performance as each successive core is utilized.

    For instance utilizing all 8 cores on an 8 core processor is negligibly faster than only utilizing 6 cores. Hence the license paid on the last two cores is a waste of money.

  • If you had ever the fun to deal with the advanced quantum mechanics of oracle licensing you're really happy with the 'all inclusive' approach of sql server.

  • I'd like to see a much more simplified licensing structure too — enterprise for everyone and charge license fees determined by a formula based on instance RAM and cores allocated to it. The more cores the SQL Server instance uses, the higher the licence fee, the more RAM (excluding In-Memory-OLTP) allocated to SQL Server, the higher the fee. 1GB RAM, 1 core and a 10GB DB limit would still be free (as the Express edition is).

    The RAM used for In-Memory-OLTP would have to be deducted otherwise would kill this new feature stone dead.

  • I've never understood why Microsoft charge per core or per CPU anyway. Do they incur extra costs if a customer has 8 cores rather than 4? If you rent a car from a hire company they don't charge you more if you plan to drive the car fast...

  • Essentially bigger customers are paying for smaller customers.

    If they charged a flat fee, it would be great for the bigger customers (because they'd pay less) and bad for Microsoft (because they'd lose many smaller customers).

  • Per core charging is a bad idea if we're talking virtual cores rather than physical.

    Hyper threading makes one physical core appear as two in the operating system to improve it's ability to multi-task. But each virtual core is much less than a physical core, it's about 60% as a best case.

  • farid.abdi (1/21/2016)


    Being charged per core is a rip-off due to the decrease in performance as each successive core is utilized.

    For instance utilizing all 8 cores on an 8 core processor is negligibly faster than only utilizing 6 cores. Hence the license paid on the last two cores is a waste of money.

    In this case you set the processor affinity to only use 6 cores, as then only buy 6 x core licenses. Regardless of what you have however, you always need to start with a min of 4 cores to fit the current licensing model. I feel that this is outdated, as MS are in a way using a legacy model of 1 processor = 4 cores, which in this virtual world that we now operate in is not really fit for purpose!

    We have some very low use, dedicated application SQL VM's which only require 2 vcpu's... however we have to buy 4 core licenses for it and cannot use CPU affinity due to the licensing model that is currently in place!

    I feel that the rule of buying 2 x core packs, but starting with a min of 2 of these packs should be changed to just allowing you to purchase in 2 core packs regardless... phew!!

    All non production environments should be covered by MSDN (subscription in place of course), regardless of either STD or EE, however for EE in QA/Dev, you can always use Developer Edition.

    Then there are of course the nuances with virtualization and license mobility, for which you must have Software Assurance unless you don't mind falling into the 90 day rule. To "SA" or not to "SA", that is the question?

    It is a very complicated subject, something which I have recently spent a lot of time working on and something that I feel could be simplified... especially where it comes to legacy servers built pre September 2012, that were not "cashed in" for equivalent core licenses at the time, which you now need to move to a newer platform.

    Originally purchased without "SA" meaning that you can re-use these processor licenses per say in a newer platform regardless of cores, however if originally purchased with "SA"... then you can't as need to convert each proc into 4 cores, which could potentially create a shortfall in cover and incur a cost!

    There are licensing boot camps, which speaks volumes about the levels of complexity.

    Lead level SQL DBA currently working for a well established Insurance organisation in London.
    www.linkedin.com/in/hadenkingslandleaddba

  • Microsoft is pricing themselves out of the market. My company is moving off it in favor of PostgreSQL. Sadness.

  • To be fair to PostgresSQL, it is a nice DB to work with. I haven't used it in a while though.

  • Microsoft is pricing themselves out of the market. My company is moving off it in favor of PostgreSQL. Sadness.

    Our smaller customers can't afford the overhead of the license fees. With the biggest economic/social collapse since 1929 on the horizon*, SQL Server licenses are becoming luxuries that only the more fortunate folks can support. 🙁

    My side and personal projects are all OSS. I spend as little time supporting SQL Server as possible, the ROI is currently greater on the alternatives. I'll keep a few Windows machines around for Office and the ilk, but the majority of the computers bought in the last couple of years run some form of Linux. There's some rougher edges in spots, but most apps just need a well maintained RDBMS.

    *(It's bleak when your normally optimistic spouse decides to cancel vacation and use the money on additional emergency supplies and such.)

    :ermm:

  • Yet Another DBA (1/21/2016)


    I think that most will use a developers copy or msdn copy for all non-production copies of sql.

    +1

    Gerald Britton, Pluralsight courses

  • They could vary the licensing by edition (which they already do to a certain extent).

    License Standard on a pre-server basis (physical or VM) with a much more limited feature set and shift to the per-core licensing for Enterprise, etc.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

Viewing 15 posts - 1 through 15 (of 36 total)

You must be logged in to reply to this topic. Login to reply