EF Core 10 Migrations and database-first are two different answers to the same question: where does your schema come from? Migrations treat the C# model as the source of truth and generate SQL from it; database-first treats the live database as the source of truth and generates C# from it. The choice is not about taste — it changes how your whole team ships features, reviews changes, and owns the schema.
This article compares the two strategies honestly: what each one optimizes, where each one hurts, and how to choose for a real project. By the end you will have a decision rule you can apply on your next greenfield application or legacy migration project, plus a hybrid path for teams that are already halfway between both worlds.
When EF Core 10 Migrations Fit Best
Code-first with EF Core 10 Migrations fits best when your domain model is the product. In an enterprise Blazor Server application organized as vertical slices, the entities are the heart of the system. Developers change C#, review a migration, and the schema follows the model automatically.
- Your team owns the schema and controls the database.
- The schema evolves quickly as features are added.
- You want schema history tracked in git and reviewed in pull requests like code.
- You need the model snapshot to keep developer machines, staging, and production in sync.
Migrations also win on velocity. Adding a property to an entity and generating a migration takes seconds, which matches how a modern vertical slice team works — small features, frequent deploys, and no database gatekeeper in the critical path of a code change.
When Database First with Scaffold-DbContext Wins
Database-first is the right tool when the database predates the application, or when a dedicated DBA team owns the schema. Instead of deriving SQL from C#, you run Scaffold-DbContext against a connection string and EF Core generates entity classes from the tables.
dotnet ef dbcontext scaffold
"Host=db;Database=erp;Username=app;Password=secret"
Npgsql.EntityFrameworkCore.PostgreSQL
--context ErpDbContext
--output-dir EntitiesThe generated classes are plain C#, so everything downstream — queries, unit tests, even your own migrations — looks normal. But the scaffold is regenerated whenever the database changes, which means hand-written customizations on generated files can be overwritten. You keep them safe with partial classes or a thin mapping layer, and you accept that the DBA team approves schema changes before they reach the codebase.
The scaffold command also accepts filters. With --table you can limit the generated classes to a subset of tables, which is useful when the database is large or shared with other systems. The --no-onconfiguring flag keeps connection strings out of the generated context, and --use-database-names preserves the database's naming conventions instead of normalizing them to C#. These switches make database-first usable in production instead of a one-time proof of concept.
EF Core 10 Migrations vs Database First in Practice
Once you have run both workflows, the difference in daily life is striking. With EF Core 10 Migrations, a schema change is a branch, a review, and a merge — the same process as any feature. With database-first, a schema change starts with a request to the DBA, an updated database, and a scaffold pass that surfaces the new shapes to the application.
Both are legitimate. The first treats the schema as application code; the second treats it as infrastructure. The mistake is mixing them casually, because then neither team is sure which artifact is authoritative and drift is guaranteed.
One practical signal settles most debates: who maintains the migration history. With EF Core 10 Migrations, the __EFMigrationsHistory table lives inside the application database and is updated by the tool, so "what changed between releases" has a versioned, queryable answer. With database-first there is no history table to read — the schema simply is whatever the DBA deployed. If your auditors ask for a change log, migrations hand them one by default.
EF Core 10 Migrations vs Database First: The Real Trade-offs
Put the trade-offs side by side:
- Source of truth: the C# model for EF Core 10 Migrations; the live database for database-first.
- Schema history: migration files in source control versus DBA scripts kept outside the repository.
- Reverse engineering: not needed with migrations; a scaffold pass on every change with database-first.
- Team dynamic: developers own the schema versus a DBA team owns the schema.
Notice that the deciding factor is not technology — it is ownership. Whichever side owns the schema should be the side that generates it. Teams that try to maintain two sources of truth end up fighting drift: the model says one thing, the database says another, and no one can say which is correct.
A Hybrid Strategy for Teams in Transition
Many teams are not starting from zero. You may already have a production database created by scripts, or a codebase full of entities with no migrations at all. The hybrid approach is to build a baseline: create one initial migration that matches the existing schema, mark it as applied, and from that point forward use EF Core 10 Migrations for everything new.
This works because the baseline migration captures the entire schema in the model snapshot. Existing tables are anchored, new changes flow through the normal add-and-update workflow, and the team gradually wins ownership of the database. For a small Indotalent CRM or HRM deployment, that is often all the strategy you need — the complete EF Core 10 schema and migration history ship inside the source, so the baseline is already built for you.
Key Takeaways
- Migrations: the C# model is the source of truth; schema history lives in git.
- Database-first: the live database is the source of truth; Scaffold-DbContext generates entities.
- Pick by ownership: whoever owns the schema should generate it.
- A baseline migration lets teams move from database-first to code-first without downtime.
- Both strategies work; only the team dynamic should decide.