Why does an entity whose primary key is generated with @GeneratedValue(strategy = GenerationType.IDENTITY) not get its INSERT statements batched by Hibernate, and what would you map instead if batching matters?

## Why the identifier decides this Hibernate's persistence context is a map from `EntityKey` — entity name plus identifier — to the managed instance. JPA also specifies that after `persist()` the entity is managed, and for generated identifiers the value must be available at latest by flush; Hibernate's implementation needs it immediately to register the instance. Whatever produces the identifier therefore constrains *when* the row can be written. ## IDENTITY: the database assigns during the insert `GenerationType.IDENTITY` maps to an auto-increment column (`AUTO_INCREMENT`, `SERIAL`/`GENERATED … AS IDENTITY`). The value does not exist until the row is inserted; the only way to learn it is to execute the `INSERT` and read the generated key back (`Statement.getGeneratedKeys()` or a `returning` clause). So `persist()` cannot merely queue an action — it must execute the statement synchronously. That has two visible consequences: 1. **Inserts happen at `persist()`, not at flush.** Ordering with other statements is fixed earlier than you might expect, and the write happens even if you never call `flush()` explicitly. 2. **There is nothing to batch.** JDBC batching accumulates parameter sets against one prepared statement in the flush-time action queue. An immediately executed insert is a batch of one, every time. Hibernate is explicit about this: insert batching is disabled for entities using an identity generator, and older versions logged a warning to that effect. Note what is *not* affected: updates and deletes against those same entities are produced at flush like any other DML and do batch normally. It is only the insert path that is lost. Bidirectional-association fixups after the insert also still batch as updates. ## The alternative: get the id before the insert ### Sequence with an allocation size ```java @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "order_seq") @SequenceGenerator(name = "order_seq", sequenceName = "order_seq", allocationSize = 50) private Long id; ``` Hibernate calls the sequence, receives a value, and — with `allocationSize` greater than 1 — uses a **pooled optimizer** so that one database call yields a block of 50 identifiers handed out in memory. The identifier is known before any row is written, so the insert is queued and flushed with everything else, and batching works. The sequence call itself is cheap and, importantly, does not have to happen per row. Two warnings about `allocationSize`. It must agree with the sequence's `INCREMENT BY` in the database, or Hibernate's pooled optimizer will hand out values that collide with other clients; Hibernate validates this when schema validation is on. And identifiers become non-contiguous — gaps appear whenever an application instance restarts with unused values in its block. Gaps are harmless unless somebody has (wrongly) attached business meaning to the number. ### TABLE generator Where sequences are unavailable, `GenerationType.TABLE` keeps a counter row in a table and can also allocate in blocks. It restores batching but introduces a hot row that every inserting transaction must update, so it serialises identifier allocation under concurrency. Prefer sequences when the database has them; MySQL gained sequence-like behaviour only via workarounds, which is why the IDENTITY/batching problem is most often met on MySQL. ### Application-assigned identifiers A UUID or client-supplied key removes the round trip entirely and batches fine. The cost is index behaviour: random UUIDs scatter inserts across the primary-key index, which hurts write locality and page cache; time-ordered variants mitigate this. Wider keys also enlarge every secondary index that references them. ## `GenerationType.AUTO` `AUTO` delegates to the dialect. On modern Hibernate 6 with PostgreSQL it resolves to a sequence, which is why the same code can batch on one database and not on another. If batching matters, be explicit rather than relying on `AUTO`. ## Diagnosing it The symptom is that `hibernate.jdbc.batch_size` appears to do nothing for inserts while updates in the same transaction batch fine, and that inserts show up in the log at the moment of `persist()` rather than at flush. Checking the identifier mapping is the first move; a proxying datasource that reports batch size confirms it. If the schema cannot change, at least accept the round trips and reduce them another way — fewer rows, fewer transactions — rather than turning `batch_size` up and expecting an effect.