3

Is it dangerous to have dev environment with a Developer Edition and Live with Standard Edition, are the binaries different ?

Improve this question
1
  • 3
    It would be helpful if you edited the question to state which version(s) of SQL Server, and service pack levels, you are using or intending to use, as the difference between editions changed significantly with 2016sp1.
    – David Spillett
    Jul 24, 2019 at 11:37

2 Answers 2

Reset to default
5

Mostly no, it isn't dangerous, but it depends on which version of SQL Server you are talking about, what parts you are using (just the DB engine?, SSIS?, SSRS?, ...) and your level of aversion to the small risk.

Developer edition is essentially Enterprise edition under a different licence. The problems you could hit are that some features might not be enabled in your production, standard edition, installation that are present in your development environment.

If you are using SQL Server 2016sp1 or above then this is unlikely to be a problem at all: almost everything is available to all editions. If you are using an older version then there might be differences to watch out for. For instance table level data compression was not supported outside enterprise (and developer) editions before 2016sp1 (including the original release of SQL Server 2016). The risk here being that one of your devs may make use of a feature that is not enabled in production. To see which features this affects, check MS's editions documentation: 2012, 2014, 2016, 2017. The risk here is small, and can be mitigated with care.

You could also go the other way: if you don't specifically need greater feature set and your dev environments don't have the data size to need more RAM than it will make use of, make your devs use Express instances then you know they won't use anything that won't be present when you deploy to Standard!

The differences beyond features between the editions and licensing options are how much RAM and how many CPUs/cores are supported. Unlike feature differences this will not cause your code to fall over because things are missing in production that are present in development, but it might cause performance differences. So again, the risk here is small. The same editions comparison pages listed above include this information also.

In any case, even if you use Developer edition for general dev, I would recommend using Standard edition in your Test environment because you want Test to be as close to Production as possible. Furthermore, matching versions and service pack levels, even if you don't match editions, is strongly recommended where possible.

Improve this answer
2
  • Great idea to use Express in the lower environments if Standard will be used in production.
    – John Eisbrener
    Jul 24, 2019 at 14:28
  • 1
    @JohnEisbrener - that was slightly tongue-in-cheek, though it would work. Just be careful if the app's dev instances might be affected by the Express edition RAM & file size limits. And turn "Auto Close" off.
    – David Spillett
    Jul 24, 2019 at 15:12
3

Developer Edition is equivalent to Enterprise, not Standard. So you could run into performance differences in Prod that you didn't have while testing in Dev. This is a good article but basically it's like having enterprise in dev and standard in prod, which I wouldn't want personally.

https://www.red-gate.com/simple-talk/sql/sql-development/edition-sql-server-best-development-work/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.