With SQL Server 2012, Microsoft changed how SQL Server was licensed – by making customers pay per core instead of per socket. While this caused grumbling among SQL Server professionals and customers, I’ve always seen it as a MOSTLY fair move on Microsoft’s part – as their goal with licensing SQL Server has always been to charge customers based upon the amount of compute being handled by SQL Server.
Where this change feels a bit less than fair, though, is when it comes to the artificial limitations put into place against SQL Server’s Standard Edition’s use of RAM (SQL Server 2012 Standard Edition was limited to an absurd 64GB of RAM, whereas SQL Server 2016 and 2016 Standard Editions are limited to a still paltry 128GB of RAM).
Stated differently, I think it’s fair for Microsoft to charge customers per core – but not if they’re going to heavily curtail how much compute you can do with this core by severely limiting the amount of RAM you can allocated per core. (Standard Edition Licenses weigh in at around $2,800 per core – but if you’ve dropped $45K for a 16 core 2014 Standard Edition box, you’re limited to a paltry 8GB of RAM per core – whereas a 2016 instance with 24 cores would cost $65,000 yet top out at a miserly 5.33GB/core of RAM – or less RAM per core (for a higher overall price).)
Yes, there are ways around this limitation (like using Buffer Pool Extensions (available on Standard Edition) or even potentially spinning up multiple instances per OSE – as the 128GB RAM limitation is per instance NOT per host), and Enterprise Edition really isn’t that expensive when you compare it to Oracle or even when you think about how much it will DO for you in a given year (and compare how much it costs per year to, say, what you’d pay 2 or 3 employees per year).
Still, I think there might be a better way: Enable up to 32GB of RAM per each 2-core Standard Edition ‘pack’ licensed. With this approach, a simple 4-core VM could pull off up to 64GB of RAM, a ‘decent’ Standard Edition instance with 8 cores could pull off up to 128GB of RAM (the max currently in place today) and a higher-end 2016 box with 24 cores (i.e., 12x 2-core packs) could top out at 384GB of RAM.
Arguably, this approach would add a tiny bit of additional complexity into the licensing landscape (and orgs running 4-core boxes today with 128GB of RAM would obviously find fault with my ‘logic’), but I’d wager that medium to large Standard Edition instances would benefit tremendously – to the point I’d even guess that Microsoft Support Services would probably field a slightly smaller number of support calls for performance related issues simply because of the extra benefits additional RAM can provide to SQL Server workloads.
No responses yet