Spin off database for different environments

Question

Hello all, Greetings!

We have to spin off Azure sql database for 5 multiple environments like DEV, QA, QA2, etc. We still have do not have pipeline setup for DB creation, and are taking care manually.

1. Shall we create DB for the respective environment when required like first DEV, then QA, later on others? I feel this will come with an overhead of reminding the DB spin off tasks every time we publish code on respective environments.
2. Or, we shall create all DBs together to avoid the overhead? Will there be any impact on the pricings?

I want to know best practice in this respect.

---

Thank you,

Kanak

Answer 1

Cost wise, the difference depends on the SKU that you choose, if you have any of the serverless options in your environments then pre-creation of the DBs could potentially, depending on your setup, be not much more than creating them dynamically. If those are on the provisioned tier, then that argument might swing the other way. I'd suggest trying to use the cost calculator to get an idea of how much each option will cost (https://azure.microsoft.com/en-gb/pricing/details/azure-sql-database/single/) and then try and work out the equivalent cost, in time, of deploying each dynamically through a release cycle. You should come out with an answer in cost terms that you can then combine with what works best for your team.

You also don't have to pick just one answer. We have a few environments that are permanently deployed, and the ability to roll out others in an amount of time reasonable for us, for example, if we need to do scale testing, or investigate particular issues. You also don't have to pick the solution forever, you could start out with the permanent deployment and then work on refining your deployment templates/processes to allow you to manage the environments more dynamically over time.

Best practice is probably to aim in the direction of doing things more dynamically, as it probably reflects a greater level of control and repeatability over your infrastructure and deployment processes. People will have stronger views, but in my opinion if you have a setup that works for you and your team, then that is usually the right answer.