RowVersion is a blunt instrument for optimistic concurrency.

In EF Core, RowVersion treats every data mutation as concurrency-critical.
That assumption doesn’t always hold in real systems.

In read-heavy applications, entities often mix:

• business-critical fields (e.g. Title)
• system or statistical fields (e.g. ViewCount, LastSeen, HitCount)

With RowVersion:

• a harmless counter increment
• invalidates an in-progress business edit
• and surfaces as a DbUpdateConcurrencyException

Not because of a semantic conflict ,
but because all mutations are treated equally.

A more intentional design is to scope concurrency to business intent, not storage changes.

Using [ConcurrencyCheck] on selected properties:

• reduces false contention
• preserves optimistic guarantees where they matter
• improves UX without weakening data integrity

Concurrency is a modeling decision, not a framework default.
Design it around what should conflict, not what happened to change.

Most developers analyze their system design by designing a system that keeps latency constant as throughput increases. Of course, this definition is correct, but the point is that in this regard, more attention is paid to the scaling category (focusing on horizontal scaling) and all the solutions offered are in line with this concern. And the point that always remains is the consistency and concurrency category. Many developers forget that for all software with a very serious and important problem that lurks like a hidden danger to seriously affect constancy and throughput. The name of the problem? concurrency

Now the point is that all the solutions proposed to solve this problem neutralize and make ineffective all or at least a large part of the measures taken to scale and increase throughput

But...

Wait

Is this really the case?