Trace Flag/sp_configure Option to Allow Developer or Evaluation Editions to "Act" like Standard Edition
One of the challenges for many customers who need to use Standard Edition is that both Developer and Evaluation Editions of SQL Server are the same functionally as Enterprise Edition. This means that in non-production scenarios/environments, without buying a full license of Standard Edition (or having MSDN), you are potentially using (or able to use) features not available in Standard. Dev and Eval should have a way to allow those who will ultimately be using Standard to constrain what features are used as well as any performance limitations in Standard so their eval/dev/testing efforts are accurate.
Thank you for filing this feedback item. We will evaluate this for the next major release of SQL Server.
Dear SQL Server Leads,
With the disruption in the last years of several DB technologies, many of them opensource, it would be nice to have SQL Server Standard as well supported as the Enterprise edition. Having the possibility of configuring Developer as Standard will help people to assess the performance.
As said in other replies, there are still several differences: Basic AG, no read-aheads, no advanced scanning, no online index rebuilds, no online DDL changes, and more that makes Developer Edition NOT VALID for testing db deployments in non-prod environments that have Standard in Prod. Not having this option, it can discard MSSQL from the options when choosing technology for a software development project.
This is something that MS should have provided since a long time ago.
"A wise man changes his mind, a fool never will"
Travis Page commented
With the release of 2019 this further blurs the line on the problem because customers may desire to try TDE using standard edition for less critical workloads that may still be subject to compliance obligations. Expand this scenario to providing basic HA and the feature option is utilizing basic availability groups with standard edition in a production workload. To create a matching development environment one cannot simply use developer edition any longer as this feature is restricted. The environments will now be fundamentally different. In many companies this is not an acceptable method of development as the configuration should be as close as possible to the production configuration to avoid introducing defects.
If one chooses to attempt to use standard edition in the non production environment this results in a number of questions which licensing partners appear to be in a position where they aren't quite ready to answer them. If this exists on prem then there are a certain set of license options that fit, cloud with Azure a different set of options, cloud with a non-Azure scenario yet another set of options. This leads to a lot of confusion for customers and license partners which in my perspective could be alleviated for both parties with a feature like this.
Matt Gordon commented
This is a common sense addition to the product that will make evaluation decisions MUCH easier for customers. Please strongly consider this change.
Hari Bathula commented
This really Helps the SQL Server community, Should not be a big effort for MS to implement.
This a really good idea and long past due. We too struggle with features and performance in our development environments not matching production when using Standard edition.
Mujib Khan commented
This would be fantastic feature as we struggle after developer might have tested a feature on developer edition but when we go to production and use Standard Edition, particular feature may not be available.
Restricting in developer edition based on Production use will help avoid such issues.
Jason Jystad commented
This would be a game changer in 3 specific situations I have seen come up more than once over the years:
1) Training, design validation, and demos of Edition specific functionality: This would be for conducting staff trainings, proof of concept exercises in design phases, and presentations or demos.
2) Application Edition Compatibility testing: Verifying required continued down-level Edition compatibility during application testing on an ongoing basis. This has been a real issue for my team requiring extra infrastructure and administration overhead to handle the need.
3) Prevention of accidental dependency on Enterprise features: I have been involved with several different teams over the years who worked on applications and services that ended up with an Enterprise Edition feature dependency accidentally. In most of these it turned out that they could have satisfied the design goals easily with Standard Edition but "just went that direction" because their Dev Edition had the feature and they didn't realize it would require additional, quite expensive, licensing.
but I've also seen several teams accidentally code themselves into Enterprise edition dependency when they didn't need it, simply because dev and eval are Enterprise.
In all of these situations, some way to force an instance to behave like another Edition temporarily would allow for much more elegant and lower overhead solutions.
Please *strongly* consider this.
David 'justdave' Williams commented
I cannot blog on Basic Availability Groups /demo it at speaking events as there is no Evaluation for Standard Edition. I complained to Microsoft at events and they was no interest. I should not have to pay to help remote the product!
Pat Phelan commented
This is a great idea, and I would suggest including this for SQL 2012 onwards if that is feasible.
R.J. Troudt commented
Extremely desirable feature!
Adam Koehler commented
This would be great as it would help us determine what features we could develop for our products without worrying that we're using an Enterprise only feature.
Daniel Maenle commented
I would also appreciate Express as an option, so if I could only get Standard I would gladly take it.
Allan Hirt commented
For me, this isn't just about features. It's also about limitations. For example, number of replicas, number of DBs in a replica, maximum amount of memory, etc. Microsoft may be thinking it's just feature differential, and there is some of that, but the only thing that acts like Standard and Standard. There are even some HA features not supported in Standard (such as distributed AGs) which would be great NOT to have.
Kendra Little commented
This is extremely desirable for database development, and would also give people the ability to compare how much faster Enterprise Edition can make things and present real metrics to their leadership on why it's worth the money. It's hard for database folks to quantify benefits of things like the "Online non-NULL with values column addition" feature presently because they don't have the ability to easily test against the same dataset on the same hardware.
Glenn Berry commented
This functionality has been asked for multiple times in the past, with no success. The most recent rejection was because of the fact that many previously EE-only programmability features were added to SQL Server 2016 Standard Edition SP1, which made this functionality unnecessary. This ignores the fact that there are still some EE-only features and performance differences between SE and EE. There are also license limits for things like sockets, cores, and memory in Standard Edition.
Hal Berenson commented
Back for SQL Server 2000 it occurred to me that having an SE-compatible Dev edition would be useful, but we were trying very hard to minimize the number of editions so went with just the EE-compatible. It didn't matter too much because the application visible behavior differences between the editions were non-existent for 7.0 and minimal (e.g., Materialized Views come to mind) for 2000. But I think SQL Server has come so far that it has long made sense to have some way for developers to be able to test against either a new SE-Dev/Eval edition or use a startup traceflag to get equivalent server behavior.