You remove a single element from a Hibernate-owned collection — an @ElementCollection or a unidirectional @OneToMany — and the SQL log shows a DELETE for every row of that collection followed by re-INSERTs of the survivors. Why does Hibernate do this, and how do you stop it?

## The mechanism When Hibernate initialises a persistent collection it stores a **snapshot** of its contents. At flush it diffs the live collection against that snapshot and decides on statements. The question it must answer for each change is: *which database row does this element correspond to?* For a set, the answer comes from the element itself — the child entity's identifier, or the full value tuple for a value collection. For an indexed list, the `@OrderColumn` value answers it. For a **bag** there is no answer: the mapping explicitly allows two indistinguishable elements, and there is no index column. Hibernate therefore falls back to the only sound reconciliation available: *recreate*. It deletes every row belonging to the owner and re-inserts the collection's current contents. Internally this is the `needsRecreate` path on the collection persister: a bag whose contents changed at all (not merely appended) is not updatable in place. ## Which mappings are affected Only collections whose rows Hibernate is responsible for writing: - `@ElementCollection` — a value collection with its own table. - Unidirectional `@OneToMany` with `@JoinColumn`, or with an implicit/explicit join table. - The owning side of a `@ManyToMany` (the join-table rows). Not affected: a bidirectional `@OneToMany(mappedBy = "parent")`. That collection is the inverse side; it drives no DML at all. Removing an element there produces nothing by itself — the child's `@ManyToOne` owns the FK, and deletion comes from `orphanRemoval` or an explicit `remove`. This distinction is what separates a real answer from the folk rule "never use List in Hibernate". Also worth noting: a pure **append** to a bag can be handled with a single `INSERT` — Hibernate does not need to recreate when nothing was removed or reordered. The pathological case is removal or mutation in the middle. ## Why it hurts more than statement count - **Write amplification.** Removing one of 500 rows writes 500 statements (or one multi-row delete plus 499 inserts). At scale that is orders of magnitude more work. - **Index churn.** Every re-inserted row is a fresh index entry in every index on the table; the deleted ones become dead tuples the engine must clean up. - **New identifiers.** For an `@ElementCollection` with a surrogate key, or a join table with a synthetic id, the re-inserted rows are new rows. Anything outside the ORM that referenced them — an external report, a cached id, an audit trigger — sees a mass delete and a mass insert rather than a single change. - **Lock footprint.** Rows that did not change are still written, so they are still locked for the duration of the transaction, widening the window for contention with other writers. - **Replication and CDC noise.** Change-data-capture consumers see the whole collection change every time one element does. ## The fixes, in preference order **1. Map it as a `Set`.** For an `@ElementCollection` of values or a many-to-many, uniqueness is almost always the correct domain semantics anyway, and Hibernate can then target rows. Watch the `equals`/`hashCode` requirement for entity elements: a hash derived from a generated id changes at flush and breaks the set. **2. Add `@OrderColumn`** when order is genuinely part of the domain. The collection becomes an indexed list: removal is a `DELETE` plus renumbering `UPDATE`s for the elements after it. Cheaper than recreate for long collections with tail-biased changes, more expensive for head insertions. **3. Make the one-to-many bidirectional** with `mappedBy` on the parent, `@ManyToOne` on the child, and `orphanRemoval = true`. The inverse collection drives no DML and the child's removal is one `DELETE`. As a bonus this drops the join table or the extra FK-update statement that unidirectional `@JoinColumn` mappings produce. **4. Do not model it as a mapped collection at all.** For large or high-churn child sets, query children explicitly and mutate them with targeted operations or bulk statements. A collection mapping is a convenience for aggregates that are small enough to load whole. ## How to spot it Turn on SQL logging (`hibernate.show_sql` / a statement-count assertion in tests) and assert on statement counts for the mutation path. A test that fails when one removal produces N statements is the durable defence — a code review of annotations alone will not catch it, because the mapping looks perfectly reasonable.