I spend a lot of time working with software houses, helping them to make their applications work well with SQL Server. One thing that I’ve heard loud and clear over the years is that most software houses won’t write a single line of code that will only run on the enterprise edition of SQL Server, because they are not prepared to limit their potential pool of customers to those running enterprise edition.
This is completely at odds with the discussions that I’ve had with the SQL Server marketing team members who think that having feature differences will cause people to purchase enterprise edition instead. I’m sure that’s true for customers who write their own applications in-house and is also why at promotional events, the customers that you see mentioned are often those types of customers. However, most SQL Server customers run 3rd party applications written by other companies. The customers will often ask the software houses what software is required to run their applications and they then purchase what they need, unless they have some other pre-existing form of relationship with Microsoft.
So this means that having a difference in features can actually cost Microsoft money as the customers will often purchase standard edition because that’s all the software that they will be running requires.
Worse, when software houses are comparing SQL Server to other database engines, they compare SQL Server standard edition to the other engines, not the enterprise edition. This makes SQL Server compare badly for marketing reasons instead of technical reasons. For example, I saw a software house the other day comparing SQL Server with PostgreSQL. Their contention was that PostgreSQL (a free database engine) had a good high availability story and that SQL Server did not. Their logic was that SQL Server only had mirroring (and log shipping) and Microsoft had announced the deprecation of mirroring. So their contention was that SQL Server did not have a good availability story. The fact that enterprise edition had a really good story was irrelevant as they don’t consider anything in that version.
A further issue appears with coding. There is no developer edition of SQL Server that is limited to standard edition features. Software houses want to write code once and have it work across all target editions.
Another core issue is that this focus on enterprise edition has removed the upgrade reasons for standard edition customers. I think that every edition should have a compelling upgrade story, for every version. As an example, in SQL Server 2014, the reasons to upgrade for standard edition customers are the ability to use 128GB of memory and to have backup encryption. I’ll leave it to the reader to decide if that’s a strong story. I don’t think it is.
The final issue with the existing situation is that the product is moving into areas that need support from software houses. SQL Server 2014 introduced a range of in-memory options. For any customer that can’t change the code (ie: most customers), this is irrelevant. Again you’ll see the same large customers who write their own apps being mentioned in the launch events. I this case, I think the marketing team really have made a mistake. While new HA features, etc. can be retrofitted by a DBA to an existing database, the new in-memory options really need to be architected into the design of the applications. And that’s where it’s a real problem that it’s in enterprise edition only. The software houses are unlikely to use it, and yet they are exactly the same people that we need to embrace it.
So what does this have to do with Azure?
Bob Beauchemin wrote a great blog post today about how Azure SQL Database is moving to a SQL Server 2014 code base. That’s a great thing but one aspect that caught my eye was the mention that this is the first version of Azure SQL Database where features like columnstore indexes, etc. will only appear in the premium editions of Azure SQL Database.
While I’ve had concerns about how the licensing has been handled in the on-premises versions of SQL Server, in Azure SQL Database this concerns me even more. I really think that Azure SQL Database should offer the same code surface no matter which edition you are using. It makes sense to have performance and availability (including HA) options differ between Basic, Standard, and Premium but I really don’t like the idea of coding/feature differences. First up, it will again see software houses ignoring useful features. But worse, in the Azure SQL Database arena, customers are much more likely to use a mix of database editions than they currently do on-premises.
For example, if I am offering an application as a service, I want to be able to have different databases for different tenant customers. I really want to be able to choose the performance, reliability, availability options, etc. on a tenant by tenant basis, not across all tenants that are using my application. Having coding differences across the editions would make this a mess, or at least I think so.
I’d love to hear your thoughts.
Table partitioning is available in all tiers of Azure SQL DB. In fact I just created a PARTITION FUNCTION in a standard database and it worked. (Command(s) completed successfully.:-))
In-memory columnstore is the only feature which is limited to premium.
Hi Tony, that's really good news but the same issue still applies regardless of what the feature differences are. Having columnstore in only premium will be a reason for people to avoid using it, and makes the product look less capable.
Also, how would I work with a multi-tenant app where different customers need different availability and performance arrangements? That means that I'd either have to stop using columnstore even for the premium customers or limit my customers to only premium editions. Neither is a good option IMHO.
Much of the focus on Enterprise Edition comes from the sales folks at Microsoft. They see Standard Edition as stealing potential Enterprise Edition sales. SInce their compensation is primarily tied to Enterprise SKUs, they actually would be perfectly fine if Standard Edition simply went away. So Microsoft ends up making marketing decisions based on how it compensates its sales force instead of how to maximize its overall revenue and market share.
Awesome pickup thanks Chris. I've updated it to 128GB 🙂
And also thanks Tony, I've removed the reference to the table partitioning.
And interestingly, the doco on the preview page is quite confusing. It appears to say that table partitioning, online indexing, large index rebuilds are premium only. I think it's only meant to indicate that parallel queries are premium only. (And later mentions columnstore)
I think a good reason for upgrading to SQL Server 2012 or 2014 Standard could be not because of the new technical features, but because of the changes in Licensing (e.g. Software Assurance providing license mobility rights).
I agree with you and think full functionality should be available to all customers.
The cloud revenue model is a totally new ball game and they don't need to stick to the per cpu model ( multiplied by how many planets are currently aligned) used in client hosted installations. The current licensing fees are not straight forward to work out!
Microsoft should be heading towards an elastic model where you pay by usage or some other creative revenue model enabled by the cloud infrastructure. I mean, they are hosting it all for you right? They can meter data transfers and cpu usage and see all sorts of monitoring stats. You'd want to have some sort of lenient capping model on there too because you don't want to screw customers with an unexpected massive bill for one particularly heavy usage month. Maybe not a PAYG but more of a reconciliation and EOFY.
Behind the scenes of Azure they could be running some kind of elastic APS/PDW thing and spinning up new nodes as required, and working that into the revenue model as well. Docker anyone?
I'd also like to see student & startup breaks as well. I can't fault Microsoft on that front, they already do put effort into that area.
Hi
Also if: columnstore is only premium editions, and i will scale down to standard – will it stop working?