Pagination with JpaRepository and Pageable

Direct Answer

A Pageable carries a zero-based page number, size, and optional Sort. A Page contains content plus total counts and therefore normally needs a count query; Spring Data may avoid that query when it can infer the total. A Slice reports only whether another slice exists and usually fetches one extra row instead of counting all matches. The provider renders database-specific limiting SQL, not always literal LIMIT/OFFSET.

Code Example

@RestController
@RequestMapping("/api/orders")
public class OrderController {
    private final OrderRepository orderRepository;
    OrderController(OrderRepository r) { this.orderRepository = r; }

    @GetMapping
    public Page<Order> getOrders(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "20") int size) {
        int safeSize = Math.min(size, 100); // cap to protect the DB
        Pageable pageable = PageRequest.of(page, safeSize, Sort.by("createdAt").descending());
        return orderRepository.findAll(pageable); // Page includes total count
    }

    // Infinite scroll: Slice skips the count query
    @GetMapping("/feed")
    public Slice<Order> feed(@RequestParam(defaultValue = "0") int page) {
        return orderRepository.findByStatus("OPEN", PageRequest.of(page, 20));
    }
}

Common Mistakes & Pitfalls

• Page where Slice fits — on million-row tables the count query can take seconds; infinite-scroll UIs don't need totals, so use Slice.
• Off-by-one pages — pages are zero-indexed; if the frontend sends 1-based numbers, subtract 1.
• No max page size — a request for size=1000000 can overwhelm the DB; cap it (e.g., 100).
• Forgetting sort — without a stable Sort, page boundaries can shift between requests.