0

I am designing a database schema for our customers on-premise, which will be moved to Azure PaaS later.

Regarding the "scale out" strategies I lean towards to create "one database", and create schema for each and every customer to store the database objects such as tables, procedures, and views.

Although, I find little to no information how to keep track of schema changes in each and every schema, and put a version number on each. Tools such as Liquibase or Fluentmigrator has limited support for such it seems, as they seems to be better for a single database.

What are the best practices to version, and manage database schemas in a database?

Improve this question
3
  • 1
    Any reason not to separate each customer into their own database and then use schemas for version control? There's pros and cons in doing this, but generally you get better management by decoupling customers across separate databases (especially when it comes data size and growth management).
    – J.D.
    Jan 17 at 19:14
  • Azure Managed Instance can handle max 100 user dbs. I have 500. I need cross queries between customers, so need to have all custemrs on the same instance too. Not sure if elastic pools can handle 500 db thoigh, cant find that limit.
    – Avi
    Jan 17 at 20:58
  • 1
    Hmm interesting. I don't dabble much in Microsoft's other cloud services, but am pretty proficient in SQL Server and this is how I've managed data in the past (with about 500 customer databases as well). But we were running our own instances of SQL Server in the cloud. Of course with multiple SQL Server, cross-instance data access is pretty easy between Linked Servers, Replication, or Availability Groups as features, but again not sure what Azure Managed Instances have available, sorry.
    – J.D.
    Jan 17 at 22:08

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.