Under Hibernate's default flush mode, a JPQL query sometimes triggers a flush of pending changes and sometimes does not. What decides that, and why do native SQL queries behave differently?

## The problem auto-flush solves With write-behind, in-memory changes and the database disagree until a flush. If a query ran against the database while an unsent `UPDATE` sat in the action queue, the result could contradict the objects the same code just modified. The `AUTO` flush mode fixes this by flushing *before* queries — but flushing before every query would be wasteful, because most queries have nothing to do with what is pending. ## Query spaces Hibernate's compromise is the **query space**: an identifier for a table (or a collection table) that a query reads or an action writes. Because JPQL and Criteria queries are parsed by Hibernate into an internal AST, it knows precisely which entities — hence which tables — the query touches. Each pending action likewise knows its table. Before executing a query under `AUTO`, Hibernate intersects the two sets: - **Overlap** → flush the pending actions, then run the query. - **No overlap** → skip the flush; pending changes cannot alter this result. So queuing an insert into `orders` and then querying `Country` skips the flush, while querying `Order` triggers it. The optimization is real and generally invisible — but it means "AUTO flushes before queries" is a simplification, and code that relied on an incidental flush before an unrelated query can be surprised. ## Native queries: the opaque case When you write `em.createNativeQuery("select ... from orders o join customers c ...")`, Hibernate has a string it does not interpret. It cannot tell whether the SQL reads `orders`, so it cannot prove there is no overlap. The conservative default is to flush the whole action queue before the statement runs. Correct — but it means one stray native query in a batching loop can force a full flush every iteration. The fix is to declare the tables yourself: - `unwrap(NativeQuery.class).addSynchronizedEntityClass(Order.class)` — name the entity; - or `addSynchronizedQuerySpace("orders")` — name the table directly. Once declared, Hibernate treats the native query like any other: it flushes only if the declared spaces overlap the pending actions. The same declaration also drives second-level cache invalidation for that statement, which matters for native DML — an undeclared native `UPDATE` leaves cached regions stale. The reverse hazard exists too: if the native SQL writes to tables you did **not** declare, Hibernate does not know to invalidate them, and it may skip a flush that was actually needed. Declare accurately or not at all. ## Practical consequences 1. **Do not rely on a query as a way to flush.** If you need pending state in the database, call `flush()` explicitly; the overlap check may legitimately decide not to flush. 2. **Mixed JPQL and native code is a performance trap.** Native queries inside a write loop force repeated full flushes; declaring synchronized spaces, or moving the native query out of the loop, removes the cost. 3. **Stored procedures behave like native queries** — fully opaque, so the same conservative rules and the same declaration mechanism apply. 4. **`FlushMode.ALWAYS`** is the sledgehammer version: no overlap analysis, flush before everything. It is the safe fallback when you cannot reason about what a statement touches, at a cost. 5. **Bulk JPQL `update`/`delete` statements bypass the persistence context entirely.** They are still preceded by the auto-flush of *pending* changes, but their own effects never appear in already-loaded entities — those instances stay stale until you clear or refresh the context.