

And the best part is, you’ll have SQL Server running locally without needing any virtualization software.

Furthermore, matching versions and service pack levels, even if you don't match editions, is strongly recommended where possible.Here I’ll show you how to get SQL Server up and running on your Mac in less than half an hour. 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. The same editions comparison pages listed above include this information also. 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. The differences beyond features between the editions and licensing options are how much RAM and how many CPUs/cores are supported.

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

) and your level of aversion to the small risk.ĭeveloper edition is essentially Enterprise edition under a different licence. 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?.
