A Point in Time is a lightweight, named reference to a frozen view of an index’s data, letting repeated searches see a perfectly consistent snapshot even as the live index keeps changing.

The one-sentence answer

Elasticsearch stores data in indices that are constantly being written to, updated, and deleted from in real, production systems. A Point in Time, or PIT, is a lightweight object you explicitly open against one or more indices, which captures the exact state of the relevant Lucene segments at that moment, and which every subsequent search using that PIT will continue to see, completely unaffected by any writes that happen to the live index afterward, until the PIT is explicitly closed or allowed to expire.

The word “snapshot” is used loosely here, and deliberately not in the sense of Elasticsearch’s own backup snapshots, which are an entirely different feature covered elsewhere. A PIT is not a backup, is not stored durably for long-term use, and is not meant to persist for hours or days. It is a short-lived, in-memory-oriented reference, held open specifically for the duration of an operation like paging through a large result set.

What Point in Time is not

• It is not a backup or a durable snapshot. If the underlying node holding a relevant shard is lost, the PIT referencing it is lost too; it has no independent durability of its own.
• It is not a way to view historical data from the past. A PIT freezes the view starting from the moment it is opened; it cannot look backward to a point before it existed.
• It is not free to hold open indefinitely. Keeping a PIT open consumes real resources on the nodes holding the relevant shards, for as long as that PIT remains alive.

To understand why PIT exists, you first need to understand exactly what goes wrong when you try to page through search results without it.

The naive approach: paging with plain offsets

The most obvious way to page through search results is to ask for a page of results starting at some offset — skip the first one thousand, then return the next one hundred, for example. This works perfectly well for shallow paging, a handful of pages deep, against data that is not changing much. But it silently breaks down in two independent ways as soon as the underlying data changes between one page request and the next, or as the requested depth grows very large.

Problem one: the moving-target effect

Imagine you request results 1 through 100, sorted by relevance or by a timestamp, and then a moment later request results 101 through 200. If, in between those two requests, a new document was indexed that would have ranked as result number 50, every document that used to be positions 50 through 200 has now effectively shifted down by one position. Your second request, for positions 101 through 200, now returns a result set that overlaps with, or skips entirely, documents your first request already showed you, purely because the underlying ranking shifted while you were paging through it.

flowchart TD
  A["Page 1 request: results 1-100"] --> B["New document indexed,
shifts rankings"]
  B --> C["Page 2 request: results 101-200"]
  C --> D["Result set now overlaps
or skips documents from Page 1"]
  D --> E["User sees duplicates
or missing results"]

Problem two: deep pagination becomes expensive

Separately from the consistency problem, retrieving results starting at a very large offset is fundamentally expensive for a distributed search engine to compute correctly. To correctly return, say, results 50,000 through 50,100 sorted by relevance, every shard involved in the search has to compute and rank its own top 50,100 candidates internally, before the coordinating node can merge those per-shard rankings together and pick out the correct slice. The deeper the requested offset, the more work every single shard has to do, even though the final page returned is still just a small number of documents. Elasticsearch enforces a hard limit on how deep plain offset-based paging is allowed to go, specifically because this cost grows unreasonably large well before that limit is reached.

Why a consistent view is the real underlying fix

Both of these problems trace back to the same root cause: without a fixed, frozen reference point, every new page request is effectively asking a brand-new question against a target that may have already moved. Point in Time addresses this at the source, by giving every page request in a paging sequence a shared, unchanging reference to search against, so that the underlying data genuinely cannot shift out from under you partway through.

Why this problem is easy to miss in casual testing

One reason this class of bug is so common in real applications is that it is genuinely difficult to notice during casual development or testing. A developer paging through a few hundred test records in a mostly-static development index will very rarely observe any duplicates or gaps, simply because so little is changing between one page request and the next. The exact same paging code, deployed against a busy production index receiving continuous writes, can silently produce incorrect results from the very first day, without throwing any error or warning of any kind, since nothing about a duplicated or skipped record looks obviously wrong from the application’s own point of view. This gap between how the problem behaves in testing versus production is precisely why understanding it conceptually, rather than discovering it only after a customer or auditor notices missing data, matters so much.

Why this is fundamentally different from a simple caching problem

It is tempting to think of this as merely a caching or staleness problem, solvable by refreshing more often or waiting for data to “settle.” It is not. The issue is not that any individual page of results is stale or incorrect on its own; each individual page, taken by itself, is a perfectly accurate reflection of the live data at the moment it was requested. The problem is that the pages, taken together as a supposedly unified whole, no longer describe any single, coherent state of the world, because the world kept moving between one page and the next. No amount of refreshing or re-fetching fixes this; only a deliberately frozen, shared reference point across the entire sequence of pages actually addresses it.

A handful of precise terms make the rest of this guide click into place.

Why PIT and search_after are almost always used together

A PIT alone solves the consistency problem: it guarantees the data you are searching does not change underneath you. But it does not, by itself, solve the deep-pagination cost problem described in the previous chapter. search_after is what solves that second problem, by letting each subsequent page request pick up exactly where the previous one left off, using the last result’s own sort values as the starting point, rather than an ever-growing numeric offset. Used together, PIT provides the stable, unchanging backdrop, and search_after provides the efficient way to walk across that backdrop page by page.

Why a unique tiebreaker field matters so much

Sorting by a field like a timestamp alone can leave many documents with identical values, particularly at scale, where several documents might legitimately share the exact same recorded timestamp. Without a secondary, guaranteed-unique tiebreaker field, such as a document’s own internal identifier, search_after could not reliably determine a single, unambiguous “next” position whenever ties occur, risking documents being skipped entirely or returned more than once across pages.

Behind the simple idea of “freezing a view” sits a specific, deliberate mechanism involving segment readers held open across the relevant shards.

What actually gets frozen

When a PIT is opened against one or more indices, Elasticsearch does not copy any data. Instead, on every shard relevant to those indices, it records a reference to the exact set of Lucene segments that make up that shard’s data at that exact moment, effectively pinning a reader against that specific view of the shard. Because Lucene segments are immutable once written, this pinned reference remains perfectly valid and unchanging even as new segments are created, old ones are merged, and documents are deleted from the live, ongoing index.

flowchart TD
  subgraph Shard["A single shard at PIT-open time"]
    S1["Segment A"]
    S2["Segment B"]
    S3["Segment C"]
  end
  PIT["PIT reference"] -->|"pins exactly these segments"| S1
  PIT --> S2
  PIT --> S3
  NewData["New documents indexed afterward"] --> S4["New Segment D
(not part of the PIT's view)"]

Why immutability is exactly what makes this possible

This entire mechanism only works cleanly because of a property already covered as fundamental to how Lucene stores data: segments, once written, are never modified in place. Deleting a document does not erase bytes from an existing segment; it marks that document as deleted in a separate structure, while the original segment’s data remains physically present until a future merge eventually reclaims that space. A PIT takes direct advantage of this: because segments do not change underneath it, pinning a reference to a specific set of segments is enough to guarantee a stable view, without needing to copy any actual document data anywhere.

How this prevents premature segment cleanup

Ordinarily, once enough documents in a segment have been marked deleted, or once a segment becomes a good candidate for merging into a more efficient, larger segment, Lucene’s merge process will eventually reclaim and remove that old segment. An open PIT explicitly prevents this from happening to any segment it still references, effectively telling the merge process “not yet, something still needs this exact version of the data.” This is precisely the resource cost of keeping a PIT open, discussed in depth in a later chapter: held-open segments cannot be merged away or reclaimed, using more disk space and file handles than they otherwise would.

Following the full life cycle of a Point in Time, from creation through repeated use to eventual release, makes the mechanism concrete.

Why the PIT ID changes with every response

It is a common point of confusion that the PIT ID returned in a search response is not always byte-for-byte identical to the one that was sent in that same request. Internally, Elasticsearch may need to update the encoded routing or keep-alive information as part of ordinary operation, and applications are expected to always use the most recently returned PIT ID for their next request, rather than assuming the original ID from the very first open request remains valid forever unmodified.

What happens if keep-alive is not renewed

If an application stops issuing searches against a given PIT and lets its keep-alive period elapse without renewal, Elasticsearch automatically releases the pinned segment references on every relevant shard, exactly as if the PIT had been explicitly closed. This automatic expiration exists specifically as a safety net against applications that crash, disconnect, or simply forget to close a PIT they no longer need, ensuring that abandoned PITs do not tie up shard resources indefinitely.

Tracing one concrete scenario end to end shows exactly how PIT and search_after cooperate to deliver consistent, efficient deep pagination.

Setting the scene

Imagine a compliance team at a logistics company, “CargoLine,” needing to export every shipment record matching a set of audit criteria — potentially hundreds of thousands of records — into a downstream reporting system, sorted by shipment creation time. New shipments are being created continuously throughout the day, even while this export job runs.

sequenceDiagram
  participant App as Export job
  participant ES as Elasticsearch
  App->>ES: Open PIT on shipments index, keep_alive=5m
  ES-->>App: PIT ID
  App->>ES: Search with PIT ID, sort by creation time, size=500
  ES-->>App: First 500 results + last sort values + refreshed PIT ID
  App->>ES: Search with PIT ID, search_after=last sort values
  ES-->>App: Next 500 results + refreshed PIT ID
  Note over App,ES: Repeats until fewer than 500 results returned
  App->>ES: Close PIT
  ES-->>App: Acknowledged, resources released

What would go wrong without PIT in this exact scenario

Suppose CargoLine’s export job instead used plain offset-based paging, with no PIT at all, against the live, constantly-updated index. Partway through the multi-hour export, new shipments continue being created and indexed. Some of those new shipments, depending on their creation time relative to the sort order, could land at a position the export job has already passed by, meaning they would be silently skipped entirely from the export. Others could shift previously-seen records into positions the job has not yet reached, causing them to be exported a second time. For a compliance export, either outcome, silently missing records or silently duplicating them, is a serious, unacceptable defect.

How the PIT-based approach avoids this entirely

Because the export job opened a PIT at the very start and continues using that same PIT ID for every subsequent page, the entire multi-hour export effectively runs against the exact snapshot of shipment data that existed at the moment the PIT was opened. Shipments created after that moment simply do not exist within that frozen view at all, and will not appear in the export; nothing that did exist at that moment can be skipped or duplicated because of changes happening concurrently elsewhere.

Elasticsearch had a mechanism for consistent deep pagination before PIT existed, called scroll, and understanding why PIT is now generally preferred clarifies a lot about PIT’s own design choices.

How scroll worked, briefly

The scroll API worked by opening a single, long-lived search context tied directly to one specific query, returning a scroll identifier that could be repeatedly used to fetch the next batch of results for that exact query, against a frozen view of the data, conceptually similar in spirit to what PIT provides today. Each scroll request also had its own keep-alive, renewed with every subsequent request, much like PIT’s own keep-alive mechanism.

Why scroll fell out of favor for general-purpose deep pagination

Scroll’s context was tightly bound to one specific, original query and its sort order, decided once at the moment scroll was first opened, and could not be flexibly recombined with different sorting or filtering needs later on. Scroll contexts were also considered relatively heavyweight to maintain at scale, and Elasticsearch’s own guidance eventually shifted toward recommending scroll be reserved specifically for genuine, one-time full-index processing tasks, such as reindexing every document, rather than for general application-facing deep pagination use cases.

Why this shift matters conceptually

The move from scroll to PIT plus search_after reflects a broader design principle: separate the concern of “what data am I looking at” (solved by PIT) from the concern of “how do I efficiently continue from where I left off” (solved by search_after), rather than bundling both concerns into one single, rigid mechanism. This separation is precisely what gives PIT-based pagination its flexibility to be combined with different sorts, different filters, and different query shapes across successive pages, something the older, more rigid scroll mechanism never comfortably allowed.

Real production use of PIT requires deliberate choices about how long to keep one alive and how it behaves across multiple indices at once.

Choosing an appropriate keep-alive value

The keep-alive duration specified when opening a PIT is a direct trade-off between resilience and resource cost. A very short keep-alive risks the PIT expiring unexpectedly if an application briefly stalls, perhaps due to a slow downstream system it is writing exported data into, forcing an entirely fresh PIT to be opened and the paging sequence to restart. A very long keep-alive, by contrast, risks holding shard resources pinned for far longer than actually necessary if an application finishes its work early but forgets, or fails, to explicitly close the PIT.

PITs spanning multiple indices

A single PIT can be opened against more than one index at once, commonly used when an application needs a consistent view spanning, for example, a family of time-based indices that together represent one logical data set. In this case, the PIT pins segment references across every relevant shard of every matching index simultaneously, and subsequent searches using that PIT see a consistent snapshot across the entire set, exactly as though it were a single, unified index frozen at one moment.

Interaction with index aliases and rollover

Because a PIT pins specific, concrete shard-level segment references at the moment it is opened, it is not automatically aware of alias changes made afterward, such as a rollover alias being repointed to a newly created index. A PIT opened before a rollover continues to reference exactly the indices that were part of it at that moment, and will not begin including a brand-new index created by a subsequent rollover, since that new index simply did not exist yet when the PIT was created.

Because a PIT pins real, concrete resources on real shards, understanding its cost at scale is essential for anyone running Elasticsearch responsibly in production.

What pinned segments actually cost

Every segment referenced by an open PIT cannot be merged away or reclaimed, even if it would otherwise have been an excellent candidate for cleanup due to accumulated deleted documents. This means an open PIT can cause a shard to hold onto more disk space than it otherwise would, and can leave file handles open for longer than they otherwise would be, both of which are finite, real resources that a cluster has only so much of.

The compounding effect of many simultaneous PITs

A single, short-lived PIT used briefly for one export job is rarely a meaningful concern. The real risk emerges when an application pattern results in many PITs being opened frequently, held for unexpectedly long periods, or simply never properly closed due to a bug, across a busy production system. In that scenario, the cumulative effect of many pinned segment sets across many shards can meaningfully increase disk usage and degrade the effectiveness of ordinary background merging across the affected indices, in ways that can be surprisingly difficult to diagnose after the fact if nobody was tracking how many PITs were actually open at a given time.

flowchart TD
  A["Many PITs opened,
not properly closed"] --> B["Many segments pinned
across many shards"]
  B --> C["Merges cannot reclaim
pinned segments"]
  C --> D["Disk usage grows
beyond expected levels"]
  C --> E["Search performance may
degrade due to unmerged segments"]

Cluster-level visibility into open PITs

Because this risk is real and can be subtle, Elasticsearch exposes cluster-level visibility into currently open PITs and the resources they are pinning, specifically so operators can audit, at any time, exactly how many PITs exist, how long they have been open, and which indices they are affecting, rather than having to infer this indirectly from unexplained disk growth or degraded search performance alone.

Why explicit closing should be treated as a first-class responsibility

Given this resource model, explicitly closing a PIT the moment an application is finished with it should be treated with the same seriousness as closing any other limited resource, such as a database connection or an open file handle, rather than as an optional courtesy. Relying solely on keep-alive expiration as a safety net, rather than proactive closing, means resources remain pinned for longer than strictly necessary in the ordinary, successful case, purely because nobody bothered to release them the moment they were actually done.

Why failure paths deserve just as much care as the success path

A subtle but important detail is that a PIT needs to be reliably closed not only when a paging job finishes successfully, but also when it fails partway through, whether due to an application crash, an unhandled exception, or an unexpected downstream error. It is a common, easy-to-make mistake to write careful, correct PIT-closing logic for the happy path of a job completing normally, while overlooking the many other ways a real, long-running job can actually end. Robust applications treat closing a PIT the same way they would treat releasing any other critical resource: wrapped in logic that guarantees it runs regardless of how or why the surrounding job actually terminates, successful completion, an unexpected error, or an external interruption alike.

PIT is not limited to simple document retrieval; it interacts meaningfully with aggregations and with strategies for parallelizing large paging jobs.

Using PIT alongside aggregations

A search using a PIT can still include aggregations exactly as a normal search would, computed against the same frozen, pinned view of the data as the document results themselves. This is particularly valuable for workloads that need both a consistent, paginated list of matching documents and a set of consistent aggregate statistics describing that same matching set, since both are guaranteed to reflect the exact same underlying snapshot, with no risk of the aggregation numbers reflecting a slightly different, more recent state of the data than the paginated results being shown alongside them.

Parallelizing a large paging job across multiple workers

For extremely large export or processing jobs, a single, sequential stream of search_after requests against one PIT can become a throughput bottleneck. A common advanced pattern addresses this by splitting the overall document set into several independent slices, each processed by a separate worker issuing its own sequence of search_after requests, all against the same shared, underlying PIT. Because every worker is searching against the identical frozen view, the slices remain guaranteed to be complete and non-overlapping, exactly as though a single worker had processed the entire set sequentially, while allowing the actual work to proceed with meaningful parallelism.

Why slicing still depends on a correct, unique sort

Just as with single-worker search_after pagination, correctly dividing work across slices, and correctly avoiding gaps or duplication within each slice’s own sequence of pages, still depends entirely on the same discipline of sorting by a field, or combination of fields, that produces a stable, unique, unambiguous ordering across the full data set. Slicing does not relax this requirement; if anything, getting it wrong becomes more likely to produce subtly incorrect results across multiple concurrent workers rather than a single, easier-to-notice sequential one.

PIT is a genuine, deliberate trade, and understanding both sides leads to using it well rather than reflexively.

When PIT is clearly the right tool

PIT is unambiguously the right choice whenever an application needs to reliably page through a large, potentially deep result set while correctness — no duplicates, no silently missed records — genuinely matters, such as compliance exports, data migrations, or full-index reprocessing jobs.

When PIT may be unnecessary overhead

For shallow, first-few-pages-only pagination in a typical user-facing search interface, where a small amount of inconsistency between page loads is a tolerable, low-stakes cosmetic issue rather than a correctness problem, the added complexity of managing PIT lifecycles explicitly may not be worth it compared to simple, ordinary paging.

PIT’s performance profile is favorable for deep pagination specifically, but it interacts with the rest of the cluster’s resource picture in ways worth understanding.

Why PIT plus search_after scales well for deep pages

Because search_after avoids the need for every shard to internally rank an ever-growing number of candidates as page depth increases, the per-page cost of PIT-based pagination remains roughly constant regardless of how deep into the overall result set a given page happens to be, in sharp contrast to the steadily worsening cost curve of plain offset-based paging discussed earlier.

Batch size tuning

The number of results requested per page is a direct tuning lever: larger page sizes mean fewer total round-trips to complete a large export, at the cost of a larger single response payload per request; smaller page sizes mean more round-trips, each individually lighter. The right balance depends on the specific application’s tolerance for request latency versus payload size, and is generally worth tuning empirically for a given workload rather than assumed from general principles alone.

Cluster-wide capacity planning around concurrent PITs

A cluster running many simultaneous large export or processing jobs, each holding its own open PIT, should account for the cumulative pinned-segment resource cost across all of them together as part of ordinary capacity planning, rather than reasoning about each individual job’s resource footprint in isolation, since the true cost to the cluster is the sum of every currently open PIT’s pinned resources at any given moment.

Network and payload considerations for very large exports

Beyond the shard-side resource cost, sustained PIT-based paging over a very large data set also has a straightforward network dimension worth planning for: every page requested is a full round trip carrying a real payload of documents across the network, and a sufficiently large export can represent a meaningful, sustained volume of data transfer over its full runtime. Applications running very large exports should consider running them from infrastructure with adequate, reliable network capacity and proximity to the cluster, and should treat an unusually slow network path as a genuine risk factor for keep-alive expiration, not merely an inconvenience, since a slow enough page fetch can itself become the reason a PIT’s keep-alive window is exceeded.

Because a PIT references specific, live shard resources rather than durable, replicated storage, its reliability characteristics differ meaningfully from ordinary indexed data.

What happens if a node holding a relevant shard fails

If a node hosting a shard referenced by an open PIT fails or becomes unreachable while that PIT is still open, the specific pinned segment reference on that node is lost along with it. Elasticsearch’s PIT mechanism is designed to be resilient to this in ordinary circumstances involving replica shards, since a replica of the same shard, if one is available and itself already part of the PIT’s pinned view, can continue to serve that portion of the frozen data. This resilience, however, depends on replicas genuinely being available and properly configured; an index with no replicas offers no such fallback if its only shard copy is lost mid-paging.

Why long-running PITs deserve extra reliability thought

A PIT opened and closed within seconds carries relatively low exposure to any single node failure occurring in that narrow window. A PIT deliberately kept open for a long-running job spanning hours carries meaningfully more exposure simply by virtue of the longer time window during which some relevant node could experience a failure. Teams running long paging jobs against data where replica availability is uncertain should weigh this exposure deliberately, and consider whether breaking a very long job into several shorter PIT-based segments might reduce the blast radius of any single node issue occurring partway through.

PIT interacts with Elasticsearch’s access-control model in a few specific ways worth understanding for anyone responsible for a cluster’s security posture.

Access control still applies to searches using a PIT

Opening a PIT does not itself bypass or override field-level or document-level security; every search issued against a PIT is still subject to the same access-control rules that would apply to an equivalent search issued directly against the underlying indices. A user without permission to see a particular field or document type cannot see it through a PIT-based search any more than they could through an ordinary one.

PIT IDs as sensitive, capability-bearing tokens

A PIT ID is an opaque token that grants the ability to continue searching against a specific, pinned view of data. While it is scoped by the access-control context of the user who originally opened it and does not by itself grant broader access than that user already had, treating PIT IDs with the same care as other sensitive session-like tokens, rather than passing them around loosely between systems or logging them in plaintext unnecessarily, is a sensible general precaution.

Why abandoned PITs are also a minor security hygiene concern

Beyond the resource-cost concerns already discussed, PITs that are opened but never properly closed represent lingering, active capability tokens that remain valid until they eventually expire on their own. Good operational hygiene around promptly closing PITs is therefore not purely a performance consideration; it also reduces the window during which an unnecessarily long-lived, valid token exists at all.

A small set of specific signals reveal whether PIT usage across a cluster is healthy or quietly becoming a problem.

Number and age of currently open PITs

Tracking how many PITs are currently open across a cluster, and how long the oldest ones have been open, is the most direct early-warning signal available for the resource-accumulation risk discussed earlier. A steadily growing count of open PITs, or PITs surviving far longer than any legitimate job should reasonably need, is a clear sign that something, somewhere, is failing to close them properly.

Segment counts and merge behavior on affected indices

Indices with unusually high segment counts, or segments that appear to be lingering well past when they would ordinarily have been merged away, are worth cross-referencing against currently open PITs referencing those same indices, since pinned segments are one of the more subtle, easy-to-overlook explanations for otherwise-unexplained segment accumulation.

Building alerting around PIT accumulation

Because the consequences of unmanaged PITs accumulate gradually rather than failing loudly all at once, proactive alerting on the count and age of open PITs, rather than waiting to notice the downstream symptoms of degraded merge behavior or unexpected disk growth, is a meaningfully better operational posture for any team relying on PIT-based workflows at real scale.

Practical guidance distilled from how PIT is used well, and used poorly, in real production systems.

A best practice around defensive keep-alive renewal

Applications performing long, potentially slow paging jobs should choose a keep-alive value with realistic margin above their expected per-page processing time, and should treat an unexpected PIT expiration error as a signal to investigate why a particular page took unusually long, rather than simply retrying blindly with a fresh PIT and silently accepting a possible loss of consistency partway through the job.

Concrete scenarios illustrate how PIT’s guarantees actually matter to real applications built on Elasticsearch.

Straightforward answers to the questions people most often ask once they first encounter Point in Time.

Bringing everything in this guide together into a single, quick reference.

Point in Time solves a problem that only becomes visible once you try to page deeply and reliably through search results on data that never stops changing: without some way of freezing what you are looking at, deep pagination silently breaks in ways that skip records, duplicate them, or both. PIT solves this by pinning a specific, unchanging set of Lucene segments the moment it is opened, taking direct advantage of the fact that segments are immutable once written. Paired with search_after, it turns deep, consistent pagination from an expensive, fragile operation into an efficient, reliable one — at the real, ongoing cost of pinned shard resources for as long as the PIT remains open, which makes explicit, prompt closing every bit as important as opening it correctly in the first place.