Algolia Search API vs. Client Pagination: Is Stable Ordering Guaranteed Across Pages?

Goal: Stable Pagination for Large, Dynamic Indices

Developers often need to present users with a paginated view of a sizable Algolia index (tens of thousands of records). The goal is to fetch each page in sequence while ensuring that no record is omitted or duplicated, even when the index is updated between requests.

Constraints and Uncertainty

Algolia’s public API offers hitsPerPage and page parameters, and the more granular offset and length options. However, the API does not guarantee a stable ordering across successive calls when the underlying index changes. The nbHits field is computed on the fly, so its value may not reflect real‑time updates. Additionally, the API lacks a native cursor‑based mechanism, forcing developers to implement custom logic if they wish to track state (e.g., using the last record’s primary key). These factors create uncertainty about whether offset‑based pagination can reliably deliver consistent results for large, frequently updated datasets.

Unresolved Questions

1. Does Algolia guarantee stable ordering across pages when using offset and length or page and hitsPerPage, even when records are added or removed between requests?

2. What, if any, mechanisms does Algolia provide to maintain consistency across paginated results for dynamic indices?

3. For indices that exceed a few thousand records and receive frequent updates, is a custom cursor strategy (e.g., filtering by a monotonically increasing primary key) recommended, and what are the trade‑offs in terms of latency and API usage?