Does Hibernate 6 offer a native keyset pagination API compatible with Spring Data JPA repositories?

Direct answer

No. Hibernate 6 does not expose a first-class keyset-pagination abstraction that plugs into standard Spring Data JPA Pageable or Page<T> repository methods. Pageable is offset-based by contract, and Spring Data translates getOffset() into setFirstResult() on the underlying query.

Confirmed facts vs. likely explanation

Confirmed: Hibernate 6 can express keyset (seek-method) queries directly through HQL, the Criteria API, or native SQL by combining a unique ordering column with tiebreakers, a WHERE predicate such as id > :lastId, and setMaxResults(). This is a low-level capability, not a Spring Data integration.

Likely explanation: The assumption that Hibernate 6 added native keyset support often comes from its improved scroll and streaming APIs. Those APIs operate on result sets and sessions, not on the Pageable contract. They do not automatically satisfy Page<T> semantics such as total element counts.

Practical integration for existing repository signatures

If you must keep existing Pageable-based call sites, do not override getOffset() to smuggle a cursor value; Spring Data will still pass that value to setFirstResult(). Instead, add a custom repository fragment that accepts a cursor or a dedicated parameter and builds the keyset predicate itself.

1. Define a custom fragment interface, for example UserRepositoryCustom, with a method like Slice<User> findAfterCursor(Long lastId, int limit).
2. In the implementation, use the EntityManager or StatelessSession to create a query with WHERE id > :lastId ORDER BY id ASC and setMaxResults(limit).
3. Return a SliceImpl (or Window if your Spring Data JPA version supports it) so callers can detect whether more rows exist without a total count.
4. Keep the read and cursor fetch inside the same read-only transaction or snapshot to avoid skips and duplicates from concurrent writes.

Version-sensitive alternative

Recent Spring Data JPA releases introduced ScrollPosition and Window<T> return types for repository methods. If your version supports them, a method such as Window<User> findFirst10ByOrderById(ScrollPosition position) can express keyset navigation without Pageable. Verify this in your build before relying on it; the exact signatures have changed across releases.

Limits to plan for

• Deterministic order: Keyset pagination requires a unique tiebreaker. Without it, rows with equal sort values can be skipped or duplicated.
• Multi-column sorts: Composite keys need cursor encoding and either row-value comparison or disjunctive predicates ((a, b) > (:a, :b) or equivalent).
• Backward navigation: Reversing direction requires reversing the sort and inverting the predicate, or using a backward scroll position if available.
• Totals: Approximate counts from database statistics (for example, PostgreSQL pg_class.reltuples) are stale and do not satisfy Page<T> semantics such as getTotalElements() or isLast(). Use them only for UI hints, not for pagination logic.
• Index dependency: Keyset only outperforms OFFSET when the ordering columns are indexed and form a stable order.

Verification steps

Before rolling this out, confirm the generated SQL uses the keyset predicate and LIMIT rather than OFFSET. Run EXPLAIN on the query or enable Hibernate SQL logging. Then test with concurrent inserts and deletes around a captured cursor to ensure no rows are skipped or repeated under your transaction isolation level.

One missing diagnostic detail

Do any existing callers depend on Page<T>.getTotalElements() or isLast()? If yes, those endpoints should remain on Pageable/offset or move to a dedicated cursor API; if no, a Slice or Window return type is the safer path.