The premise of this document is to provide reader with ideas on how to manage a growing number of reference databases as teams adopt Datical.
Introduction
During early phase of Datical adoption, teams typically setup Reference Databases on their own, i.e., they may not be using centralized infrastructure from day 1. This allows teams flexibility to manage and configure their Reference Databases as well as underlying servers. However, as Datical usage grows, the approach above would create a sprawl of Reference Databases. To better manage demand, it would be ideal to move Reference Databases to centralized/shared infrastructure.
Note that Reference Databases are typically structure-only databases without any significant amount of data. You may still need lookup data or test data to validate objects.
Reference Databases for SQL Server
You could put a large number of Reference Databases on single SQL Server instance. The number of Reference Database per instance would be dictated by the size of each Reference Database (size depends on number of objects in the database and the amount of data needed in the database).
If dealing with multiple versions of SQL Server (2008, 2012, 2014, 2016, etc.). You could setup different versions of SQL Server on the same server. Each version of SQL Server would run as a separate Database Engine instance.
The best practice, however, for scaling out SQL Server-based Reference Databases would be to arrange separate servers for each version of SQL Server. And then run only one version of Database Engine (SQL Server instance) per server.
Reference Database for Oracle 11g
Datical connects to Oracle databases using user that are also names of schemas in the database. In a pipeline that consists of DEV, QA and PROD environments, the schema name would be consistent across each environment. As such, there could be multiple Oracle instances configured for each environment.