By default the UPDATE Hibernate generates for a changed entity sets every mapped column, not just the ones that were modified. Why is it built that way, and in what situations does switching that entity to Hibernate's @DynamicUpdate pay for itself?

## Why the default writes every column Hibernate generates the CRUD SQL for each entity once, at bootstrap. For updates, that means a single statement shape per entity: `update t set c1=?, c2=?, ..., cn=? where id=?` (plus `and version=?` when versioned). One shape has several benefits: - **Prepared-statement reuse.** The same SQL string is reused across every update of that entity, so both the JDBC driver's statement cache and the database's plan cache hit rather than compiling a new statement per distinct set of changed columns. - **Batching.** JDBC batching requires statements of identical shape. With a static UPDATE, a hundred dirty entities of the same type flush as one batch; with per-change shapes they scatter into many batches, or none. - **Predictability.** The plan for the statement is stable, and the bootstrap cost of SQL generation is paid once. The price is writing columns whose values did not change. For narrow entities on ordinary types that is usually irrelevant — the row is rewritten anyway by most storage engines, so the cost is mostly bind parameters and network bytes. ## What @DynamicUpdate changes Annotating the entity with `@DynamicUpdate` makes Hibernate compose the UPDATE at flush from exactly the properties that dirty checking reported as changed. Change one column of forty and the statement sets one column. Where that matters: **Wide tables.** With 50–200 columns, rewriting everything on every small edit means bigger statements, more bind parameters, and more work in the engine's write path. **Large values.** A CLOB/BLOB/JSON/TEXT column of hundreds of kilobytes that was not touched still gets sent and rewritten under a static update: network traffic, potential out-of-line storage churn, and larger write-ahead log volume. Excluding it is a real saving. **Trigger and change-data noise.** Triggers, audit tables and CDC pipelines that key off “which columns appeared in the statement” see every column on every update, producing audit rows and downstream events for changes that did not happen. Dynamic updates make the statement reflect intent. **Reduced write footprint under concurrency.** This is the nuanced one. A dynamic update does **not** make lost updates impossible — two transactions writing the same column still race, and that is what a version attribute is for. What it does remove is the *needless* overwrite: a transaction that only edited a note no longer rewrites a status another transaction changed since it read. In systems without versioning it materially reduces silent clobbering; it is not a substitute for a proper concurrency token. **Versionless optimistic locking.** Hibernate's `@OptimisticLocking(type = OptimisticLockType.DIRTY)` (and `ALL`) builds the WHERE clause from the previously loaded values of the changed (or all) columns, so the update only succeeds if the row still looks as it did at load. Because the WHERE clause varies with what changed, this strategy requires dynamic updates. It is the escape hatch for legacy tables where adding a version column is not possible — with the caveat that it cannot detect a change made and undone, and it makes statement shapes explode. ## The costs, stated honestly - **SQL generated per flush.** String building and parameter binding for each dirty entity, instead of reusing one prepared shape. - **Weaker caching.** Distinct column combinations mean distinct SQL strings, so driver and database statement caches see many shapes; on databases where hard parsing is expensive, this can outweigh the saved bytes. - **Weaker batching.** Only updates that changed the same columns can share a batch, which in a bulk job is often the case (the same field is being updated everywhere) but in mixed workloads is not. ## How to decide It is a **per-entity** annotation, and that is how it should be used. Reach for it when the entity is wide, holds large columns, or feeds triggers/CDC — or when versionless optimistic locking is required. Leave it off for small entities and for entities updated in bulk with uniform column sets, where batching dominates. As with all such switches, measure: statement counts and shapes, batch sizes, and bytes written before and after. A useful side effect worth mentioning: turning it on temporarily is a great **diagnostic**. If an entity is producing mystery updates, a dynamic update names the offending column in the SQL log immediately, which a static all-columns statement never does.