Why I Don’t Like Shared Development Databases This editorial was originally published on Jan 31, 2020. It is being republished as Steve is out of town. When working with Redgate customers who are starting to improve their software development pipeline and delivery practices for databases, I find that many folks are using a practice which I consider outdated and harmful for both code quality and release velocity: the shared development database. Shared development databases are problematic for code quality for a few reasons. First, a shared development environment limits innovation as well as initial testing: if I am a developer on a team using a shared database, I will personally be quite unlikely to try many experiments. This is because anything I change in that database could impact others; they are using the same schema and the same data. I will also be hesitant to change around test data and indexes much to do any testing for performance – after all, the more changes I make, the more risk that I could accidentally cause issues for someone else. There is also the risk that changes I make to a shared development database may be accidentally overwritten or picked up by someone else. This risk is major, because if someone overwrites my changes before I commit and I don’t realize it, I could end up accidentally deploying the wrong changes. Some products like SQL Source Control offer object locking to mitigate this risk, but that introduces other problems: the more objects I need to lock, and the longer I need to lock them, the more I may impact other people on my team who now need to wait to do any changing or testing of changes to those objects. There are even more downsides to the shared development database. Troy Hunt has done a fantastic job of documenting these problems in his classic post, “The unnecessary evil of the shared development database,” which he published in 2011. Since the publication of his post, the only major changes which have occurred are that SQL Server Developer Edition is now free from Microsoft (instead of available at a low cost), and developers have more options than ever before to use provisioning and storage technologies to create lightweight, writeable copies of even the largest production datasets. Many offerings for this, such as Redgate’s SQL Provision, include tooling to mask / de-identify production data and provide fast on-demand creation of databases for development and test. While products that help you efficiently manage dedicated databases for development do cost money, slow or poor quality releases can easily cost your organization far more – so I encourage you to make 2020 the year in which you assess if you can provide better development environments for your team, using whatever tech stack is right for your organization. Kendra Little Join the debate, and respond to today's editorial on the forums | 
