Performance & Tuning

Use a constructor expression: select new com.app.UserDto(u.id, u.name) from User u. Name the class fully qualified and give it a constructor whose parameter types match the selected expressions in order. Results are plain objects, not managed entities.

Set hibernate.show_sql=true to print to stdout, or better, set the org.hibernate.SQL logger to DEBUG so SQL goes through your logging framework. hibernate.format_sql pretty-prints it. Parameters stay as ? until you enable TRACE on Hibernate's bind-parameter logger.

EAGER fetches the association on every load path, even queries that never use it — extra selects per row or cartesian products from joined collections. It cannot be switched off per query. Map everything LAZY and fetch explicitly per use case with fetch joins or entity graphs.

For each managed entity Hibernate builds the instance, keeps it in the persistence context, and stores a second copy of its loaded state for dirty checking. Every flush then compares all of them property by property. A DTO row costs one small object and none of that.

Set hibernate.jdbc.batch_size to a positive number, for example 30. Hibernate then buffers statements with addBatch and calls executeBatch when the batch fills, when the SQL string changes, or at flush. Statements only batch at flush time, so nothing batches before a flush occurs.

With IDENTITY the database assigns the key during the INSERT, and persist() must return a managed entity that already has its identifier, so Hibernate executes the INSERT immediately instead of queuing it for flush. Nothing accumulates, so nothing batches. Use a sequence with an allocation size instead.

Entities are put in the persistence context without a loaded-state snapshot, so Hibernate cannot dirty-check them and never flushes an UPDATE for them. That removes roughly half the per-entity memory and all flush-time comparison work.

A command-oriented Hibernate API opened from the SessionFactory that has no persistence context. You call insert/update/delete explicitly. You lose the first-level cache, dirty checking, write-behind, cascades, collection handling, lifecycle events and interceptors, and second-level cache interaction.

Count the statements the request emits first. The usual causes: lazy loads in a loop, EAGER mappings pulling graphs, loading whole tables and filtering in Java, no pagination, entity graphs serialized to JSON, and per-row writes. Evidence before fixes.

The persistence context. Every entity pulled from the cursor is registered with a state snapshot and stays strongly referenced. Fix: load read-only and call session.clear() every N rows — or select a projection instead of entities.

Nothing at all. There is no dirty checking, so the field change is invisible until you call update(entity) — which then writes every mapped column. Collections are ignored and cascades do not run, so the new child is never inserted; you must insert it and set its foreign key yourself.

getResultList() reads every row and builds every entity before returning. getResultStream() and scroll() keep a database cursor open and hand you rows as you pull them, so peak memory depends on how much you keep, not on the result size. Both must be closed.

Every persisted entity stays managed, so the persistence context grows to 200,000 entities plus dirty-check snapshots. Each flush re-checks all of them, so work grows quadratically. Flush and clear in fixed batches, enable JDBC batching, or use a stateless write path.

Object[] gives positional untyped values — fine for a throwaway query. Tuple adds access by alias and element type, still generic. A DTO or record gives named, typed fields checked by the compiler and is the right choice for anything crossing a service boundary.

Fetch size is how many rows the JDBC driver pulls from the server per round trip. Hibernate sets it globally with hibernate.jdbc.fetch_size or per query. Some drivers buffer the entire result unless a fetch size (plus driver-specific conditions) makes them open a server-side cursor.

It makes Hibernate count its own work into a Statistics object reachable from the SessionFactory: statements prepared, entities loaded/inserted/updated/deleted, queries executed with their times, collection and cache hit/miss/put counts, connections and flushes. Counters are cumulative until you clear them.

The context accumulates every entity it ever loaded: unbounded memory, flush cost proportional to that count, stale data that is never re-read, and accidental writes flushed at commit. Lazy loads fired during serialization also hide fan-out. Use one short session per unit of work.

Start from the response payload, write a query selecting exactly those columns into a DTO, push filtering, sorting, paging and aggregates into SQL, and drop the entity load. Watch for lost lazy navigation, formatting logic that lived on the entity, and per-row work now missing.

A batch can only hold one SQL string, so interleaved entity types break it after every statement. order_inserts and order_updates sort the flush-time actions by entity type (and updates by primary key) so identical statements become contiguous and fill batches. Cost is sorting at flush plus changed statement order.

Statement logging prints each statement as Hibernate prepares it, so it never shows batching. Prove it with a proxying datasource such as datasource-proxy or p6spy that reports batch size, with TRACE logging on Hibernate's JDBC batch internals, or by counting round trips at the database.

Count statements around the code and assert on the count. Either clear Hibernate's Statistics and assert getPrepareStatementCount(), or wrap the DataSource with datasource-proxy/p6spy and assert its captured query count. Run the assertion in a single-threaded test against a real database dialect.

Decide by how much ORM machinery the rows actually need. Flat rows with no cascades or callbacks: StatelessSession, or plain JDBC if mappings add nothing. Graphs, events or auditing: batched Session with flush/clear. Pure single-table dumps: the database's native bulk loader beats all three.

upsert() writes a row without you knowing whether it already exists — one insert-or-update statement, typically SQL MERGE where the dialect supports it. It needs the identifier already assigned on the entity, and like all stateless writes it writes every mapped column.

It controls whether UPDATE and DELETE statements for entities carrying a version column are sent in JDBC batches. Hibernate decides a row was changed concurrently from the affected-row count; if a driver returns SUCCESS_NO_INFO from executeBatch, that check cannot be made, so batching must be disabled.

Set hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS to a millisecond threshold. Hibernate then logs each slower statement to the org.hibernate.SQL_SLOW category with its elapsed time, measured client-side around JDBC execution — so it includes network and server queueing, unlike the database's own log.

Caching makes existing lookups cheaper; it does not remove queries a bad fetch plan issues. Cache only small, read-mostly, by-id-accessed reference data, with an explicit size cap and expiry per region, and measure the hit ratio. Fix fetch plans first.

Keep one database and one schema. Commands load entities by id and mutate them; queries run projection queries into per-use-case DTOs and never return entities. Costs: two sets of types over one schema, duplicated knowledge of the mapping, and weaker reuse of entity behaviour and caching.

Measure rather than guess. Start around 30 to 50, raise it while throughput improves, and stop when gains flatten. Chunk the work into bounded transactions, flush and clear per chunk, avoid identity keys, and check whether the driver rewrites batches before tuning further.

Trade consistency against operability. One cursor gives a single consistent read but pins a connection and a transaction for hours and restarts from zero on failure. Chunking by a stable key gives restartability and short transactions, at the cost of a moving snapshot.