Search code examples
sqlsql-serverazurereplication

What is the most logical way to store multiple versions of a database in a SQL Server instance?


We operate a website in AWS that uses Azure as the data source. Azure is populated by transactional replication from our customers. Once every 3 or 4 months a new version of the customer database is released. My company does not make this customer database. More often than not, the new version does not come with an update script and basically all the customer information is wiped and the new database version is a fresh create.

How do I maintain an uninterrupted history in the cloud through these updates? I see only two options: create a new database for each version, create a new schema for each version. The first will get expensive over time, the second feels hacky. If it's such a big deal should I just make my own update scripts?


Solution

  • To keep expense down, consider Elastic Pools for your Azure SQL DBs. Elastic pools have an allocation of eDTU's that can be shared between N databases as needed. As long as the sum total of DTU's used by all databases in the pool do not exceed the max DTU's for the pool, you're golden.

    I assume that older versions of your database need to be accessible, but probably don't have much (or any) traffic. By hosting older versions in the same elastic pool, you can drastically reduce cost and still have them accessible if needed.

    The other option would be to take backups of older versions, then restore them if ever needed.