EF Core's defaults pass code review, then meet the second replica

Twelve rows in local development against five thousand in production is roughly a 400x difference in volume ^[1], and five thousand rows is still a table you could scroll through by hand. The other two triggers the dev.to post names are one extra replica and a request that gets cancelled halfway ^[2]. That is the useful part of the framing: none of these thresholds are large.

Note the asymmetry in how the author treats them. The only failure with a full mechanism attached is the deployment one, and it is not EF Core's doing. Calling `db.Database.Migrate()` at app startup with five pods booting together produces a half-migrated schema at 3am, discovered through an alert rather than a review comment, according to the post ^[10]. Do the arithmetic on that: one runner is needed, so four of the five pods are concurrently mutating a schema nobody asked them to touch ^[2]. On a K3s deployment where multiple replicas are the entire point, the author notes this is the normal startup path ^[12], which means the shortcut's failure mode is the default configuration and not an unlucky corner of it.

The replacement is a generated idempotent SQL script, reviewed, then applied in the deploy pipeline ^[9], run once by a single runner in an init container or pipeline stage ^[11]. The substantive change is not where the command lives. It is that a person reads the DDL before it executes, and exactly one process is holding the lock while it does. The companion rule is that merged migrations are append-only, so a bad one gets a successor rather than an edit ^[13].

The ORM-side items in the sample are handled by construction rather than by explanation. A `uint RowVersion` sits on the entity from the first commit as an optimistic concurrency token, mapped with `IsRowVersion()` in a configuration class rather than by attribute ^[4][8]. Timestamps are `DateTimeOffset` in UTC, rendered in the user's zone only at the edge ^[6], and the clock arrives as `TimeProvider` so a test can assert an exact value instead of "sometime around now" ^[7]. Keys are sequential GUIDv7 for index friendliness ^[5], with a unique index on `Slug` and a composite on `(PublishedAt, Id)` ^[15]. The author's stated reason for the UTC and clock choices is retrofit cost ^[6]. The concurrency token belongs in that same category on the same reasoning: it is a line in the first migration now, and a coordination problem across every existing write path later.

One honest gap. The excerpt supplied to us stops mid-signature in the controller's `Show` action and never mentions change tracking or `AsNoTracking` ^[16]. The read path appears only as a shape: `Index` returns a `PagedResult<PostDto>` and threads the cancellation token into the service call ^[14]. Projecting to a DTO is the only tracking-adjacent decision visible in the code, and the post does not argue for it.

What holds the list together is a difference in recovery cost. A missing token or an attribute-littered entity is repairable in a migration and a pull request. A schema half-altered by four racing pods is repairable at 3am. That ordering justifies the author flagging startup migrations hardest, even though it is the one item on his list that a code reviewer looking at C# would never see.