EF Core Database Initialization: Migrations vs. EnsureCreated for Ephemeral Environments

Question

When designing a repeatable development environment for Entity Framework Core (version 8.0+), the choice of schema initialization affects how the database handles evolution and state. The goal is to establish a consistent baseline for developers and automated integration tests while minimizing startup overhead.

Database.EnsureCreated() provides a fast, clean-slate initialization by generating the schema based on the current model. However, it bypasses the __EFMigrationsHistory table, meaning any subsequent schema changes require a full database deletion and recreation.

In contrast, EF Core Migrations allow for incremental schema updates, preserving data across iterations. This approach requires managing migration files and tracking applied versions within the database, which introduces more complexity into the deployment pipeline.

Which approach is more sustainable for a shared development environment where schema changes occur frequently but data persistence is preferred?
  What are the implications of switching from EnsureCreated() to Migrations once a project moves from prototyping to a stable development phase?

Tasadduq Burney · Answer

For shared development environments where schema changes occur frequently and data persistence is required, EF Core Migrations is the only sustainable approach. While EnsureCreated() is faster for initial prototyping, it lacks the mechanism to track schema evolution, making it impossible to update the database without wiping all existing data.

Why Migrations Win in Shared Development
The primary difference lies in the __EFMigrationsHistory table. When you use Migrations, EF Core tracks which schema changes have already been applied. This allows developers to:

Apply incremental updates: Only the changes (e.g., ALTER TABLE) are executed.
  Preserve state: Seeded data and manual test entries remain intact as the schema evolves.
  Synchronize teams: Migration files are checked into source control, ensuring every member is working against the exact same database schema version.

Switching from EnsureCreated() to Migrations
Moving from a prototype to a stable development phase is not an automatic transition. Because EnsureCreated() does not populate the history table, the first migration you run will fail because EF Core will attempt to create tables that already exist.

To switch safely, follow these steps:

Baseline the existing schema: If you want to keep existing data, create an initial migration using dotnet ef migrations add Initial.
  Manually mark as applied: Since the database already has the tables, you must either manually insert the migration name into the __EFMigrationsHistory table or use the dotnet ef database update command while the database is empty first.
  Replace the initialization code: Replace context.Database.EnsureCreated() with context.Database.Migrate() in your application startup logic or CI/CD pipeline.

Implications for Ephemeral/Test Environments
In automated integration tests where databases are created per test run, the trade-off is between speed and reliability:

EnsureCreated(): Use this if your tests only care about the final schema and do not need to verify that migration scripts actually work in production.
  Migrate(): Use this if your CI pipeline must validate that the migration path is valid. This adds overhead but prevents "migration-only" errors from reaching production.

Note: This analysis assumes EF Core 8.0+. In older versions, the behavior of Migrate() is similar, but CLI tooling may vary.

EF Core Database Initialization: Migrations vs. EnsureCreated for Ephemeral Environments

1 answer

Why Migrations Win in Shared Development

Switching from EnsureCreated() to Migrations

Implications for Ephemeral/Test Environments

Your perspective belongs here.

1 question comment