EF Core 10 named default constraints give SQL Server predictable names with one migration caveat

Named defaults arrive in EF Core 10

EF Core 10 introduces named default constraints for SQL Server. Until now, SQL Server assigned default constraints machine-generated names such as DF__Jobs__Status__..., which are effectively impossible to predict ahead of time. That complicates life for deployment scripts, DBA runbooks and rollback procedures that need to refer to a constraint by name. According to a dev.to write-up, the new feature fixes this by giving every default a stable name.

There are two ways to use it. You can pass a name directly to HasDefaultValue or HasDefaultValueSql on individual properties, or enable a model-wide convention by calling UseNamedDefaultConstraints() inside OnModelCreating. With the convention switched on, defaults defined on a Jobs entity produce names like DF_Jobs_Status, DF_Jobs_CreatedUtc and DF_Jobs_RetryCount — deterministic and readable.

The catch: the next migration rewrites every default

The convention is not a harmless metadata tweak when applied to an existing schema. Microsoft's EF Core 10 release notes, as cited in the dev.to post, warn that the next migration renames every default constraint in the model. A CI build that merely checks whether migrations compile will not reveal how wide the change actually is.

Mechanically, the generated migration consists of AlterColumn operations for each affected column. The CLR type and the default value stay the same; what changes is the addition of a Relational:DefaultConstraintName annotation carrying the new name. In the emitted SQL, EF queries sys.default_constraints to discover the opaque old name, drops it, alters the column and re-adds the constraint under the predictable name, repeating that sequence once per default.

Previewing the SQL without a database

The dev.to author built a runnable sample around two committed migrations: InitialSchema, which represents the old model with three unnamed defaults, and NameDefaultConstraints, scaffolded after enabling the convention. Generating the script requires no live connection, because the SQL Server provider can translate the committed operations locally through dotnet-ef migrations script.

The preview shows what will actually run: constraint lookups, drops, column alterations and re-created defaults. The script does not drop any table or column, but it is still schema work worth reviewing for locking and deployment duration.

Turning the preview into a deterministic gate

Beyond a one-off read, the write-up turns the preview into executable checks. The verifier resolves EF's migration services without ever opening the placeholder connection, inspects the migration's up operations and regenerates the SQL twice from fresh contexts. It asserts that exactly three AlterColumn operations exist, that the script contains three DROP CONSTRAINT statements, that the three expected DF_ names appear, that sys.default_constraints is consulted three times, that DROP TABLE and DROP COLUMN are absent, and that the placeholder connection stays closed. Running the verifier five times yielded identical output.

The author favours these semantic assertions over snapshotting the entire SQL file, because provider patches can change whitespace, batch separators or local variable names without altering meaning. If someone adds a fourth default later, the test fails on purpose and forces a scope review instead of silently accepting a wider migration. The approach answers what the migration intends to do without requiring SQL Server, credentials or a disposable database, so it functions as a contract test rather than an integration test. The author still recommends applying the migration to a representative database before production, since an offline script cannot predict lock duration, workload contention or provider permissions — in line with Microsoft's own guidance that generated migrations should be reviewed and customised.

When to hold back on the global convention

For a brand-new schema, the global convention is the convenient choice because the names exist from the very first migration. For a large or busy database, the write-up suggests a staged rollout: the API is SQL Server-specific, and the property-level overloads let you name selected defaults first, which keeps an unrelated model edit from ballooning into a broad migration. The author also cautions against reading the operation count as a performance estimate — three quick changes in a demo say nothing about hundreds of defaults sitting on hot production tables.

Why it matters

A small configuration flag that quietly reshapes a migration is a classic upgrade hazard. Named default constraints genuinely improve SQL Server operability, but the same one-line convention that tidies names also touches every default in the model the next time a migration is generated. Teams upgrading to EF Core 10 should preview the migration script — which, as the write-up demonstrates, needs no live database — and consider asserting the expected scope in CI, so the size of the change is reviewed before deployment rather than discovered during it.