Handling Migrations in Shared Databases

In this lesson, you will learn how to safely synchronize schema changes when multiple independent services rely on the same underlying database.

When your C# application is one of many services touching a single database, the standard approach—running dotnet ef database update automatically at startup—becomes dangerous. If Service A and Service B both try to apply migrations simultaneously, you risk race conditions, table locks, or inconsistent schema states.

The Decoupling Strategy

To manage this, you must separate migration generation from migration execution. In a shared environment, your application should ideally have its migrations bundled but should not be responsible for applying them during its initialization sequence.

Instead, move the migration execution into your CI/CD pipeline. By using the generated SQL scripts (dotnet ef migrations script), you can apply changes in a controlled, repeatable manner outside of the application's runtime lifecycle.

Avoiding "Migration Collisions"

If you must allow services to interact with a shared schema, use the Additive-Only Principle. Only add new columns or tables; never drop or rename existing ones. If a migration might affect a shared table, you need a coordination mechanism.

Consider this simplified approach to prevent two services from competing:

// Instead of auto-applying, run a check to verify compatibility
// or use a dedicated migration runner tool outside the app process.
public void EnsureSchemaCompatibility(DbContext context)
{
    // Check if the current schema version matches the expected version
    var pendingMigrations = context.Database.GetPendingMigrations();
    if (pendingMigrations.Any())
    {
        // Log a warning or halt startup to avoid conflict 
        // with other services concurrently modifying the shared schema.
        throw new InvalidOperationException("Pending migrations detected in shared DB.");
    }
}

By shifting the responsibility for schema updates to a deployment orchestrator rather than the application code, you eliminate the risk of multiple services fighting over locks. This ensures that your Entity Framework Core models remain stable even when the database is a shared resource across the enterprise architecture.

Key Takeaway: In shared database environments, disable automatic migration execution at startup and rely on external CI/CD pipelines to apply schema changes to prevent race conditions and deployment conflicts.