Hibernate ORM offset pagination and JDBC collection-fetch results: where does the limit boundary belong?

When a paginated Hibernate query uses JOIN FETCH on a collection, the ORM cannot safely push the offset and limit down to SQL without risking incorrect results. Instead, it reads the full result set and applies the boundary in memory, holding the JDBC connection longer and buffering more rows. Under concurrent requests, this boundary between Hibernate ORM pagination and JDBC collection-fetch results can turn a query that looks fast in isolation into a source of connection-pool wait time and heap pressure.

The unresolved decision is whether to keep the paginated root query free of collection fetches and load associations separately so the database can apply native LIMIT/OFFSET, or to accept the in-memory boundary and mitigate the concurrency cost. The exact behavior and log wording vary across Hibernate major versions and dialects, so the trade-off is a fetch-plan choice rather than a single fixed defect.

Where should the offset and limit boundary sit for this query shape? What concurrency profile makes the in-memory approach acceptable? Which Hibernate versions treat this as a documented caveat rather than a regression?