How do you decide which rows in a model carry a version, and what does the granularity of that choice cost?

## The question is not whether, but where Adding a version column is cheap; adding it everywhere by reflex is still a decision worth making consciously, because each one changes how two concurrent writers interact. Three questions decide it per row type: 1. **Is this row edited concurrently in practice?** Reference data written once by an import and read forever does not need a guard. 2. **Is the state that must stay consistent contained in this row?** If yes, a version here is sufficient. 3. **Does a rule span several rows?** Then no per-row version protects it, and the granularity question begins. ## Root versus child When an object is really a small cluster - an order with its lines, a document with its sections - the version can sit on the root, on each row, or on both. | Placement | What it protects | What it costs | |---|---|---| | Root only | Rules that span the cluster; any concurrent change under the root collides | False conflicts between genuinely independent edits | | Each row | Exactly that row's contents | Nothing spanning rows; two valid child writes can be jointly invalid | | Root plus rows | Both, if the root is advanced deliberately on child writes | Most contention, and the discipline to remember the root every time | The honest framing is that a coarse version is a **deliberate serialisation**: it makes concurrent editors of one cluster take turns. That is a feature when the cluster has invariants, and pure friction when it does not. The failure to avoid is picking coarse by default and then discovering the conflict rate on the busiest cluster in the system. ## The versionless variant Some layers can guard a write without a dedicated column by putting previously loaded values into the `WHERE` clause - either all mapped columns, or only the ones being changed. It is the fallback for tables whose schema you cannot alter. - **No schema change**, which is sometimes the entire argument for it. - **Wide predicates.** Every column in the comparison, on every write, and the statement no longer reads as a simple keyed update. - **Type fragility.** Approximate numbers, large text, and values the engine normalises on storage may not compare equal to what was read back, producing conflicts nobody can explain. - **Requires the full prior state.** A partially loaded row cannot supply what the comparison needs. - **Changed-columns-only is weaker still.** Two writers editing disjoint fields both succeed - fine when the fields are independent, wrong when a rule ties them together, which is precisely the case a guard is for. A dedicated column avoids all of this for the price of one small field, which is why it is the default whenever the schema is yours. ## Reading the feedback Granularity is a hypothesis, and production answers it: - **False conflicts dominate** - users rejected while editing genuinely unrelated things - the version is too coarse. Move it down, or split the cluster. - **Invariant violations appear under load** and cannot be reproduced by hand - the version is too fine, or the rule needs the parent brought into the write deliberately. - **Conflicts cluster on one entity or one screen** - the workflow is the problem, not the guard. A form that holds a record open for twenty minutes will collide no matter how the columns are arranged; shortening the window, or splitting the record so people edit different rows, beats any tuning of the mechanism. Measuring this needs the conflict to be recorded with the row type involved, which is worth building before the argument arrives rather than during it. ## Organisational edges Two things make this a lead's problem rather than a developer's. First, the rule that every writer advances the version has to hold across teams and jobs, and it only holds if it is written down somewhere people read. Second, granularity leaks into the client contract: what the boundary hands out as a token, and therefore what a submission must return, follows the placement. Changing a version from a child to its root later means changing what every client echoes back. ## A defensible default Start with a dedicated version column on rows that are edited by people, place it on the root of any cluster that has rules spanning its rows, leave it off write-once reference data, and use the deliberate parent advance rather than a coarse version where only some child writes touch the shared rule. Then watch the conflict rate and move, because the correct granularity is a property of the workload, not of the model diagram.