# Paged Search Larger than 10,000 Records

**URL:** <https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500>\
**Category:** Elasticsearch\
**Created:** [March 27, 2025, 6:45pm UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500 "2025-03-27T18:45:29Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Devan](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@Devan](https://discuss.elastic.co/u/Devan)\
**Post date:** [March 27, 2025, 6:45pm UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/1 "2025-03-27T18:45:29Z")

</div>

We are currently using from and size pagination in our Elasticsearch results of ~1,000 records on average. We recently ran into some instances of ~15,000 records and expect some more of similar magnitude, resulting in the 10,000 record cap causing issues.

Users can navigate to specific pages and change the size of the pages in real time, which search after and scroll search don't seem to support. Would increasing the value for index.max\_result\_window to 20,000 or 30,000 and continue to use from and size pagination be our best option in this case, or is there a more efficient method?

[Paginate search results | Elasticsearch Guide [8.17] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html)

---

<div class="post-metadata">

**Author:** ![Artem\_Shelkovnikov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/artem_shelkovnikov/32/134322_2.png) [@Artem\_Shelkovnikov](https://discuss.elastic.co/u/Artem_Shelkovnikov)\
**Post date:** [April 15, 2025, 9:19am UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/2 "2025-04-15T09:19:55Z")

</div>

Hi @Devan,

I believe that there is no better way than `search_after`. I know some applications had to drop the feature of adjustable page size because of it.

Alternatively, you can think of adjusting relevance metrics for your search so that the user does not have to page so far to find what they are looking for.

---

<div class="post-metadata">

**Author:** ![Devan](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@Devan](https://discuss.elastic.co/u/Devan)\
**Post date:** [April 17, 2025, 6:47pm UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/3 "2025-04-17T18:47:29Z")

</div>

search\_after appears to require parameters from the previous page's results, so it wouldn't allow for users to jump between pages right?

The groups of items ranging anywhere from ~100 to ~15,000 are already filtered down. If being able to navigate to any page by entering a page number is a requirement, no more than 100 items at a time, is that only really doable with the "from" and "size" parameters?

---

<div class="post-metadata">

**Author:** ![Kathleen\_DeRusso](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kathleen_derusso/32/132039_2.png) [@Kathleen\_DeRusso](https://discuss.elastic.co/u/Kathleen_DeRusso)\
**Post date:** [April 17, 2025, 7:08pm UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/4 "2025-04-17T19:08:34Z")

</div>

If you absolutely need that level of random access, you probably have to use from/size and increase your context window.

The only other suggestion I have is to look at the requirements of your search application. Is randomly paginating that deep truly required or can your application for example send in additional filters to return smaller overall result sets? It really depends on your use case and what you're trying to achieve. For many search use cases, there is no need to go that deep into search results.

---

<div class="post-metadata">

**Author:** ![Rafa\_Silva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rafa_silva/32/147814_2.png) [@Rafa\_Silva](https://discuss.elastic.co/u/Rafa_Silva)\
**Post date:** [April 18, 2025, 3:36am UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/5 "2025-04-18T03:36:37Z")

</div>

Hi! 👋

When your result sets go beyond 10,000 documents, using `from + size` starts to introduce performance and memory overhead — especially with high `from` values like `15000`.

* * *

### ✅ Recommended Options

1. **Use `search_after`**  
Great for sequential pagination. Fast, lightweight, and doesn’t scan skipped results like `from` does.
2. **Use `search_after` + Point-in-Time (PIT)**  
Ensures consistent results even if the index is being updated. Start with:

json

```auto
POST /my-index/_search/point_in_time?keep_alive=1m

```

1. **Hybrid Strategy**  
Use `from + size` for the first ~2,000 results, then switch to `search_after` for deeper pages.

* * *

### ⚠ About `index.max_result_window`

You can increase it like this:

json

```auto
PUT my-index/_settings
{
  "index": {
    "max_result_window": 30000
  }
}

```

But this is **not scalable** and can put pressure on memory. It’s OK for occasional deep paging, but not recommended for high traffic patterns.

* * *

Let me know if you'd like help building a `search_after` example or merging pagination logic on the frontend.

—  
_Shared by an Elastic Stack user based on real-world cluster use cases._

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 16, 2025, 3:37am UTC](https://discuss.elastic.co/t/paged-search-larger-than-10-000-records/376500/6 "2025-05-16T03:37:03Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.