Hibernate Performance Tuning

By default each insert is a separate statement and round trip. Enable JDBC batching so Hibernate groups statements into one executeBatch call, and flush/clear the persistence context periodically.

spring:
  jpa:
    properties:
      hibernate:
        jdbc.batch_size: 50
        order_inserts: true
        order_updates: true
        batch_versioned_data: true

for (int i = 0; i < items.size(); i++) {
    em.persist(items.get(i));
    if (i % 50 == 49) { em.flush(); em.clear(); }   // bound memory, send the batch
}

• PostgreSQL JDBC additionally needs reWriteBatchedInserts=true to turn batches into multi-row inserts; MySQL Connector/J needs rewriteBatchedStatements=true.
• order_inserts groups by entity type so interleaved parent/child inserts still batch.
• Without clear() the persistence context grows and dirty checking slows down (O(n) per flush).

SEQUENCE with a pooled optimizer (allocationSize > 1) is best: Hibernate reserves a block of ids per database call and assigns the rest in memory, so inserts can be batched and persist does not hit the database.

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "order_seq")
@SequenceGenerator(name = "order_seq", sequenceName = "order_seq", allocationSize = 50)
private Long id;

CREATE SEQUENCE order_seq START WITH 1 INCREMENT BY 50;

• The sequence INCREMENT BY must equal allocationSize, otherwise ids collide or are wasted; a mismatch is a classic production bug.
• IDENTITY forces an immediate INSERT at persist time (so the id is known), which prevents batching and delays nothing else.
• MySQL has no sequences before MariaDB 10.3; with MySQL, IDENTITY is the practical choice, so batch via JDBC executeBatch on a different path (jOOQ, JdbcTemplate batch) for mass loads.
• GenerationType.AUTO in Hibernate 6 chooses SEQUENCE when the dialect supports it (Hibernate 5 chose the hilo-style hibernate_sequence).
• UUID v4 keys fragment B-tree indexes; prefer time-ordered ids (UUIDv7, ULID) for write-heavy tables.

Use a projection so the database returns only the needed columns, skipping hydration, dirty-checking snapshots and lazy association loading.

// Interface-based projection (Spring Data)
interface OrderSummary { Long getId(); String getStatus(); BigDecimal getTotal(); }
List<OrderSummary> findByCustomerId(Long customerId);

// Class-based DTO (record) via constructor expression
@Query("select new com.acme.OrderDto(o.id, o.status, o.total) from Order o where o.customerId = :c")
List<OrderDto> findDtos(Long c);

• Entity results are tracked in the persistence context (snapshot copy per entity): costly memory and CPU for read-only views.
• DTO projections are not managed, so they cannot be modified and persisted; they also avoid LazyInitializationException.
• Dynamic interface projections over entities with nested associations can still load whole entities; check the generated SQL.
• Native queries with @SqlResultSetMapping or Tuple work for complex reporting.

• First-level (L1): per Session/EntityManager, always on; guarantees one instance per id within the persistence context and serves repeated find calls without SQL.
• Second-level (L2): shared across sessions in a SessionFactory, stores entity state (dehydrated arrays) by id; opt-in per entity with @Cache or JPA @Cacheable, needs a provider (Ehcache, Infinispan, Hazelcast, or JCache).
• Query cache: stores result sets of id lists for a query plus parameters; entities themselves must be in L2 or each id is re-fetched (N+1 on cache hits). Invalidated whenever any table in the query is modified.

spring.jpa.properties.hibernate:
  cache.use_second_level_cache: true
  cache.use_query_cache: true
  cache.region.factory_class: jcache
  javax.cache.provider: org.ehcache.jsr107.EhcacheCachingProvider

@Entity @Cacheable
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
class Country { /* rarely changes */ }

Worth it for read-mostly reference data with id lookups. Poor for frequently updated or large tables, and risky with multiple writers outside Hibernate (stale data), bulk updates (bypass L2 unless evicted) and clustered deployments without a distributed/invalidating provider.

With FlushMode.AUTO Hibernate flushes (sends pending SQL) before transaction commit and before executing a query whose tables overlap with pending changes (to give correct results). It does not flush for unrelated queries in JPA mode; native queries may trigger a flush of everything in plain Hibernate sessions.

• Each flush performs dirty checking: compares every managed entity with its loaded snapshot, O(entities). With 50,000 managed entities every query-triggered flush is expensive.
• Loops mixing persist and queries (existsByEmail) cause repeated flushes and short inserts.
• Mitigations: smaller transactions, @Transactional(readOnly = true) for read paths (Spring sets FlushMode.MANUAL for Hibernate sessions), em.clear() in batch jobs, setFlushMode(COMMIT) for specific queries, or @DynamicUpdate where wide rows make updates costly.
• With readOnly=true, Hibernate also skips creating snapshots for entities (read-only entity loading), saving memory.

em.createQuery("select c from Customer c where c.city = :c", Customer.class)
  .setHint("org.hibernate.readOnly", true)
  .setFlushMode(FlushModeType.COMMIT)
  .setParameter("c", "Pune").getResultList();

Do the work in the database with a set-based statement, not row by row through the persistence context.

@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("update Order o set o.status = 'ARCHIVED' where o.createdAt < :cutoff")
int archiveOld(Instant cutoff);

• Bulk JPQL/HQL updates and deletes bypass the persistence context, @Version increments, entity lifecycle callbacks, cascades and L2 cache (Hibernate evicts the affected entity regions, but managed instances in memory become stale), hence clearAutomatically = true.
• For very large sets, chunk by primary key ranges (where id between ? and ?) in separate short transactions to limit lock time, undo/WAL volume and replication lag.
• If you must process entities with logic: StatelessSession (no L1/L2 cache, no dirty checking, no cascading) or batched flush/clear.
• INSERT ... SELECT and DELETE with joins can be done in HQL 6 or native SQL.

By default Hibernate pre-builds one UPDATE per entity listing all columns, so the statement can be cached and batched, but it writes every column (including large TEXT/JSON) and WAL/binlog volume grows. @DynamicUpdate generates the SQL at runtime with only the changed columns.

@Entity
@org.hibernate.annotations.DynamicUpdate
class Product { /* wide table with large description */ }

• Trade-offs: smaller writes, less contention for column-level index maintenance; but more distinct statements (cache pressure, reduced batching because batches need identical SQL).
• In PostgreSQL, updating a TOASTed large value rewrites it; skipping unchanged large columns helps.
• Use it on wide tables with big columns or when different transactions update disjoint column sets; leave off for small entities.
• @DynamicInsert omits null columns, useful when relying on DB defaults.

Databases run best with a small number of active connections close to what the CPU and disk can service concurrently. A well-known starting formula (from the HikariCP wiki) is connections = (core_count * 2) + effective_spindle_count, typically 10-20 per application instance for an 8-core database. More connections increase context switching, lock contention and memory (PostgreSQL forks a process per connection, ~5-10 MB each), reducing throughput.

spring.datasource.hikari:
  maximum-pool-size: 10
  minimum-idle: 10           # fixed-size pool recommended
  connection-timeout: 3000   # fail fast when pool exhausted
  max-lifetime: 1740000      # shorter than DB/proxy timeout (30 min)
  leak-detection-threshold: 20000

• Total across instances matters: 20 pods x 10 = 200 connections against a PostgreSQL max_connections of 100 will fail; use PgBouncer (transaction pooling) or fewer pods/threads.
• Little's law: pool size needed ~ throughput x average connection hold time. If each request holds a connection for 50 ms and you need 400 req/s, you need ~20 connections; cut hold time before growing the pool.
• Tomcat threads (200 default) far exceeding pool size is fine as long as hold time is short; queue waits show as Connection is not available, request timed out.

The pool is exhausted: all connections are checked out and new requesters wait until the timeout. Causes are leaks, long transactions, slow queries, or too small a pool for the hold time.

Investigate:

• Metrics: hikaricp_connections_active, pending, usage (hold time) histogram; compare active to max.
• leak-detection-threshold logs a stack trace for connections held too long.
• Thread dump: many threads waiting in HikariPool.getConnection while others sit in remote HTTP calls inside @Transactional.
• DB side: pg_stat_activity showing idle in transaction sessions.

Common culprits and fixes:

• Remote calls or sleeps inside a transaction: move them outside.
• Open Session In View (spring.jpa.open-in-view=true, default) holds the connection until the view is rendered: set it to false.
• A nested REQUIRES_NEW calling while the outer transaction holds a connection: with a pool of N and N threads each needing two connections, deadlock-like starvation occurs. Size the pool at least threads x 2 or avoid nesting.
• Connection released only after streaming a large response.

Two different caches matter:

1. Hibernate query plan cache: caches parsed HQL/JPQL and its translation to SQL (hibernate.query.plan_cache_max_size, default 2048). Dynamically built queries with inlined literals or huge IN lists with varying sizes create unique strings, fill the cache and cost parse time and heap.
2. JDBC prepared statement cache: per connection, reuses parsed server-side statements. PostgreSQL JDBC (prepareThreshold=5, preparedStatementCacheQueries=256) switches to server-side prepared after 5 executions; MySQL Connector/J needs cachePrepStmts=true, prepStmtCacheSize=250, useServerPrepStmts (HikariCP no longer caches statements itself, leave it to the driver).

spring.jpa.properties.hibernate:
  query.plan_cache_max_size: 2048
  query.in_clause_parameter_padding: true   # pad IN lists to 1,2,4,8,16... parameters

• Always use bind parameters (never concatenate values): it prevents SQL injection and enables plan reuse.
• A varying IN (?, ?, ?) list length creates a separate plan per length; padding reduces the variety to powers of two.
• A PostgreSQL generic plan after the 5th execution can be worse for skewed values; plan_cache_mode = force_custom_plan resolves it.

For a List without an @OrderColumn (a "bag"), Hibernate cannot identify elements, so changing the collection deletes all join-table rows and reinserts the remaining ones. For a unidirectional @OneToMany mapped via a join table, adding one element can cost 1 + N statements.

Fixes:

• Prefer a bidirectional mapping with @ManyToOne on the child as the owning side and mappedBy on the parent, so adding a child is a single INSERT.
• Use a Set with proper equals/hashCode for unordered collections (updates by element identity).
• Use @OrderColumn only when order matters (shifts indexes on insert/remove at the head).
• Do not load huge collections just to add one child: childRepository.save(new Child(parentRef)) with em.getReference(Parent.class, id) avoids loading the parent's collection.

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
private Set<OrderLine> lines = new HashSet<>();

Use them for high-volume ETL, imports or exports where entity state tracking has no value. StatelessSession has no first-level cache, no dirty checking, no cascading, no lazy loading, and no L2 interaction; each operation executes immediately (inserts can still use JDBC batching).

try (StatelessSession ss = sessionFactory.openStatelessSession()) {
    Transaction tx = ss.beginTransaction();
    try (ScrollableResults<Product> rs = ss.createQuery("from Product", Product.class)
            .setFetchSize(1000).scroll(ScrollMode.FORWARD_ONLY)) {
        while (rs.next()) { /* process */ }
    }
    tx.commit();
}

• Streaming on PostgreSQL needs autocommit=false and a fetch size, otherwise the driver loads the entire result; MySQL needs useCursorFetch=true or Integer.MIN_VALUE fetch size.
• For massive inserts, JdbcTemplate.batchUpdate or PostgreSQL COPY outruns any ORM; Hibernate 6.5 introduced StatelessSession upsert/insert-multiple helpers.
• Keep ORM for business logic with invariants and cascades; choose the tool by workload.

Combine application-side counts with database-side timings.

logging.level:
  org.hibernate.SQL: DEBUG
  org.hibernate.orm.jdbc.bind: TRACE      # bind values (Hibernate 6)
spring.jpa.properties.hibernate:
  generate_statistics: true
  session.events.log.LOG_QUERIES_SLOWER_THAN_MS: 25

• Statistics exposes query count, entity load/fetch counts, L2 hit/miss ratios and the slowest query string.
• Datasource-proxy or p6spy count statements and measure per-request timing; tests can assert maximum query counts.
• Database side: pg_stat_statements, slow query log, EXPLAIN (ANALYZE, BUFFERS) of the captured SQL with real parameters.
• APM traces (OpenTelemetry JDBC instrumentation) show query counts per endpoint.
• Do not leave show-sql or statistics at full detail in production: logging every statement is itself a bottleneck.

Hibernate only invalidates L2 for changes it performs (or bulk HQL/JPQL it knows about). Direct SQL, other services, native queries without a declared synchronized space and database triggers leave the cache stale until expiry.

Strategies:

• READ_ONLY: fastest, entity never changes (reference data); an update throws.
• NONSTRICT_READ_WRITE: no locking; brief staleness window after updates; good for rarely changed data.
• READ_WRITE: soft locks to guarantee read-committed semantics for changes made through Hibernate.
• TRANSACTIONAL: full JTA transactional cache (Infinispan); expensive.

Fixes:

• Set a TTL and cache eviction on the region (<expiry> in Ehcache config).
• Evict programmatically: sessionFactory.getCache().evictEntityData(Product.class, id); for native writes declare addSynchronizedEntityClass(Product.class) on the native query so Hibernate evicts that region.
• Do not cache data with multiple writers; consider Redis with explicit invalidation via an application-level cache (Spring Cache) instead.
• In a cluster, use a provider with distributed invalidation (Hazelcast, Infinispan, Ehcache with Terracotta) or each node caches independently.

Check the executed statements with a statement-counting proxy (the SQL log alone cannot tell if they were batched). Typical causes:

• GenerationType.IDENTITY ids disable insert batching for that entity.
• Interleaved statements of different entities/tables without order_inserts / order_updates, which splits batches at each change of SQL.
• @DynamicUpdate or sparse nulls with @DynamicInsert produce different SQL strings per row, so each differing statement closes the batch.
• Entities with @Version and batch_versioned_data=false (default true in Hibernate 6 only on drivers that report correct counts).
• The driver ignores batching without reWriteBatchedInserts / rewriteBatchedStatements; the batch is still sent in one round trip but executes as individual statements on the server.
• Auto-flush mid-loop due to queries (existsBy...) or per-row save() followed by lookups.
• cascade operations hitting many types, and Oracle returning SUCCESS_NO_INFO for updated counts.
• Flush happening at fewer than batch_size entities because flush() was called after every row.

// verify with datasource-proxy: expect 1 batch of 50 statements, not 50 batches
assertThat(queryCount.getInsert()).isEqualTo(1);   // batch counted as 1 execution
assertThat(queryCount.getTotal()).isLessThan(5);