Hello Bytebase Community,

I am currently working on a multi-tenant SaaS product where I use a Database Per Tenant architecture with Azure SQL Databases. Each database contains two internal SQL schemas for logical separation:

• common_schema: Contains tables that are shared across all tenants.
• tenant_schema: Contains tables specific to each individual tenant.

Use Case:

• I would like to manage these schemas in Bytebase with a clear separation:
  • A single Bytebase project for managing the common_schema, ensuring consistent deployments across all tenant databases.
  • Individual Bytebase projects for managing the tenant_schema for each tenant, allowing tenant-specific changes to be handled independently.

Challenges:

One concern I have is how Bytebase's drift detection will behave in this setup. Specifically:

• If I create separate Bytebase projects for the common_schema and tenant_schema, will there be issues with drift detection when changes in one schema are detected as "drift" by the other project's drift check?
• For example, if a change is made in a tenant_schema, could the Project_CommonSchema detect this as drift when checking the overall database schema, even though the change is outside its intended scope?

Questions:

1. What strategy can I use in Bytebase to manage this type of setup effectively? Is it feasible to configure Bytebase projects to specifically target individual schemas for migration and drift detection, and if so, how?
2. How can I adapt Bytebase’s drift detection to avoid false positives when changes in one schema are unrelated to another?
3. Are there best practices or configuration recommendations for handling multi-schema management in a database, ensuring that schema-specific drift detection works as intended?

Any insights, guidance, or shared experiences with similar multi-tenant setups and schema management in Bytebase would be greatly appreciated!

Thank you!