Index sorting is a per-index setting, fixed at creation time, that forces every document inside every Lucene segment to be physically stored in a specific, chosen order.

The one-sentence answer

Elasticsearch organizes the documents in an index into pieces called shards, and each shard’s real, searchable data lives inside Lucene structures called segments. By default, documents land inside a segment in whatever order they happened to be indexed, sometimes called index order or insertion order. Index sorting is a configuration applied when an index is created that instead forces every segment to keep its documents physically arranged in ascending or descending order of one or more chosen fields, rather than leaving them in arbitrary insertion order.

The key phrase here is physically arranged. This is not a setting that changes how search results are presented to a user, and it is not the same thing as adding a sort clause to an individual search request, which any Elasticsearch user can already do regardless of index sorting. Index sorting changes something much deeper: the actual, on-disk byte layout of the documents themselves, inside the files that make up a segment.

What index sorting is not

• It is not a substitute for a sort parameter on a search request. You can, and usually still do, specify sorting explicitly on searches regardless of whether index sorting is enabled.
• It is not something you can turn on for an existing index in place. Because it changes the physical layout of every segment, it can only be applied when an index is first created, or by reindexing data into a newly created, sort-enabled index.
• It is not free. Every advantage index sorting provides at search time is paid for with additional work at indexing time, discussed in depth throughout this guide.

To appreciate why index sorting exists, you first need to understand what a search actually has to do when documents are stored in arbitrary order.

The default: documents land wherever they happen to land

When a document is indexed into Elasticsearch without index sorting configured, it is simply appended into whatever segment is currently being built, in whatever order indexing requests happened to arrive. Two documents with wildly different values for, say, a timestamp field, might end up sitting right next to each other physically, purely because they happened to be indexed around the same moment in wall-clock time, which has nothing to do with the values inside the documents themselves.

What a sorted search has to do without index sorting

Now imagine a search asking for the ten most recent documents, sorted by that timestamp field, descending. Without index sorting, Elasticsearch has no shortcut: it must examine the timestamp of essentially every matching document across the relevant segments, compare all of these values against each other, and only then determine which ten happen to be the most recent. Even though the final answer is just ten documents, arriving at that answer required inspecting a potentially enormous number of candidates, because nothing about their physical position hinted at which ones were worth looking at first.

flowchart TD
  A["Search: top 10 documents,
sorted by timestamp descending"] --> B{"Is the index sorted
by timestamp descending?"}
  B -->|"No"| C["Must examine timestamps
across many/most matching documents"]
  B -->|"Yes"| D["Most recent documents already
sit at the front of each segment"]
  D --> E["Can often stop reading
after the first few matches"]
  C --> F["Slower: work scales with
total matching documents"]
  E --> G["Faster: work scales with
requested result size"]

The core insight: matching the physical layout to the common query pattern

Index sorting’s entire value proposition rests on one simple insight: if you already know, in advance, that your queries overwhelmingly ask for results ordered by a particular field, you can pay a one-time cost, at indexing time, to physically arrange the data that way, so that the much more frequent search-time work becomes dramatically cheaper. This is a classic engineering trade of moving cost from a frequent, latency-sensitive operation onto a less frequent, more tolerant one.

Why this problem is not solved by adding more hardware alone

It is tempting to assume that a search examining more documents than strictly necessary is simply a matter of needing more compute power or faster disks. In reality, the fundamental issue is algorithmic: examining every matching document to find the top few, by definition, means the amount of work grows with the total number of matches, no matter how fast the underlying hardware is. Index sorting changes the nature of the problem itself, rather than merely making the existing approach run faster, which is why it can deliver order-of-magnitude improvements that raw hardware upgrades alone cannot match for this specific class of query.

Why this becomes more pressing as data volume grows

The gap between an unsorted approach and a sorted one is not a fixed, constant difference; it widens steadily as an index accumulates more data over time. An index holding a single day’s worth of events might see only a mild difference between sorted and unsorted retrieval of the most recent handful of results, since there simply are not that many candidates to examine either way. The same index, a year later, holding hundreds of millions of accumulated events, faces a dramatically different picture: an unsorted approach’s cost has grown in step with that accumulated volume, while a properly sorted approach’s cost, thanks to early termination, has stayed roughly the same, tied only to how many results were actually requested rather than to how much historical data now sits behind them. This growing gap is exactly why index sorting tends to matter most, and be recommended most consistently, for exactly the kind of continuously growing, time-ordered data that logging and monitoring systems produce.

A problem search engines have solved before, in different forms

The underlying idea of paying an upfront organizational cost to make a frequent, latency-sensitive operation cheaper is not unique to Elasticsearch or even to search engines generally. Database index structures, sorted file formats, and even simple techniques like maintaining a pre-sorted leaderboard rather than re-sorting scores on every lookup all rest on the same underlying principle. Index sorting is Elasticsearch and Lucene’s specific application of this long-established, general pattern to the particular problem of physically arranging documents within a segment.

A handful of precise terms unlock the rest of this guide.

Why this is a per-index, permanent decision

Index sorting is not a runtime toggle. It is declared as part of an index’s settings the moment that index is created, and Lucene begins physically arranging every segment accordingly from that point forward. Because this ordering is baked directly into how segments are built and merged, there is no supported way to switch it on for an index that already contains data without reindexing that data into a fresh index configured with the desired sort settings from the start.

Sort direction is a statement about your dominant query pattern

Choosing descending order on a timestamp field is a direct bet that most of your important queries want the newest data first, which is overwhelmingly the common case for logging, monitoring, and event-stream use cases. Choosing ascending order instead would be the right bet for a workload that predominantly needs the oldest, earliest records first. There is no universally correct direction; the correct choice is whichever direction matches how your actual queries are shaped.

Index sorting is implemented through a small number of settings applied at index creation, enforced consistently by Lucene across every segment and every merge.

Where the configuration lives

Index sorting is expressed as a small set of index-level settings supplied when the index is created: which field or fields to sort by, the order for each, and, where relevant, how to handle multi-valued fields and missing values. Once set, these settings become a fixed characteristic of that index, stored alongside its other configuration, and every node hosting a shard of that index enforces the same sort behavior when building segments for it.

flowchart TD
  A["Index creation request
with sort settings"] --> B["Index-level configuration:
sort field(s), order, mode, missing"]
  B --> C["Every shard of this index
inherits the same sort configuration"]
  C --> D["Every new segment built
for any shard is sorted accordingly"]
  D --> E["Every segment merge
preserves the sort order"]

Single-field versus compound sorting

The simplest configuration sorts by exactly one field, such as a timestamp. Elasticsearch also supports compound sorting, where multiple fields are supplied in order of priority: the first field is the primary sort key, and any additional fields act as tie-breakers, applied only among documents that share an identical value for every field ranked ahead of them. Compound sorting is common in workloads where a primary field alone does not uniquely or usefully order documents, such as sorting first by a coarse category and then by a fine-grained timestamp within that category.

How sort mode handles multi-valued fields

Some fields can legitimately hold multiple values per document, such as a field recording several tags or several recorded measurements. Because a physical sort ultimately needs one representative value per document to compare against others, index sorting supports a mode setting, commonly the minimum or the maximum among a document’s values, to deterministically pick that single representative value whenever a sort field happens to be multi-valued for a given document.

How missing values are placed

Not every document is guaranteed to have a value for the chosen sort field, particularly in indices with an evolving or partially optional schema. Index sorting lets you explicitly choose whether documents missing the sort field are placed at the very front or the very back of the resulting order, rather than leaving their position ambiguous or arbitrary.

Following a batch of documents through the indexing pipeline reveals exactly where and how the sort order gets physically enforced.

Why sorting has to happen again during every merge

It might seem like sorting a segment once, when it is first created, should be enough forever. But Lucene periodically merges multiple existing segments together into fewer, larger ones, purely for efficiency reasons unrelated to sorting. Since each of the segments being merged is independently sorted, but the combined set of documents from all of them together is not automatically sorted as a whole, the merge process has to interleave and re-sort the combined documents to produce one single, correctly sorted, larger output segment. This is real, ongoing background work that continues for as long as the index keeps receiving new data and undergoing merges.

What this costs, concretely, at indexing time

Sorting a batch of documents before writing them, and re-sorting combined documents during every merge, is additional computational work that a non-sorted index simply does not have to do. This shows up as measurably higher CPU usage during indexing and during merges, and in some cases as somewhat higher indexing latency, compared to the same workload running against an index with no sort configuration at all.

Tracing one concrete scenario end to end makes the abstract mechanics in the previous chapter feel real.

Setting the scene

Imagine a fleet-monitoring company, “RoadPulse,” indexing vehicle telemetry events into an index configured with index sorting on a timestamp field, descending. Dashboards built on top of this index almost exclusively ask for the most recent handful of events for a given vehicle, so the team deliberately chose to pay an indexing-time cost in exchange for near-instant recent-event queries.

sequenceDiagram
  participant Fleet as Vehicle telemetry stream
  participant Buffer as In-memory buffer
  participant Seg as New segment (sorted)
  participant Query as Dashboard query

  Fleet->>Buffer: Events arrive in arbitrary arrival order
  Buffer->>Seg: Refresh triggers segment build
  Seg->>Seg: Documents sorted by timestamp, descending
  Query->>Seg: "Most recent 20 events for vehicle X"
  Seg-->>Query: Newest documents already at the front — early termination

What happens without index sorting, for comparison

Had RoadPulse left index sorting disabled, the exact same dashboard query, asking for the twenty most recent events for a given vehicle, would have required scanning through every matching event for that vehicle across the relevant segments, comparing timestamps, before determining which twenty actually qualified as the most recent. For a vehicle with a long telemetry history, this could mean touching thousands of documents to answer a query that only ever needed the newest twenty.

Why the benefit compounds as data grows

Notice that the gap between these two scenarios widens as the vehicle accumulates more historical data. A workload with only a few hundred documents per vehicle would see a modest benefit from index sorting; a workload with millions of historical events per entity sees a dramatically larger one, because the unsorted approach’s cost keeps growing with total data volume, while the sorted approach’s cost, thanks to early termination, stays roughly tied to how many results were actually requested.

Extending the example to a fleet-wide dashboard

RoadPulse’s engineers later extend this same reasoning to a fleet-wide operations dashboard, which asks a subtly different question: not “the most recent events for one vehicle,” but “the most recent events across the entire fleet, regardless of vehicle.” Because the index is sorted purely by timestamp, descending, across all documents rather than scoped to any one vehicle, this fleet-wide query benefits from exactly the same early-termination guarantee, since the very front of each relevant segment already holds the most recent events fleet-wide, not merely for a single vehicle. This illustrates an important generalization: the early-termination benefit is not limited to queries that also filter down to a narrow subset of documents; it applies just as directly to broad, fleet-wide queries, as long as the requested sort still matches the index’s configured physical order.

The team does notice one nuance worth recording for future reference: queries that filter to a narrow subset, such as a single vehicle, and then sort by timestamp tend to see the largest relative improvement, since the unsorted alternative for that narrow case would have had to sift through a comparatively large fraction of that vehicle’s history to find just a few recent entries. Broad, fleet-wide queries still benefit meaningfully, but the improvement, while still substantial, is somewhat less dramatic in relative terms, since an unsorted fleet-wide query already has a larger overall pool of candidates to draw its top results from at any given moment.

Early termination is the single mechanism responsible for most of index sorting’s real-world performance benefit, and it deserves a careful, dedicated explanation.

The guarantee that makes stopping early safe

A search engine can only safely stop scanning a segment before reaching its end if it can prove, with certainty, that nothing further along could possibly outrank what has already been found. Without any guarantee about physical ordering, that proof is impossible — the very next document could, for all the engine knows, have the most extreme value seen so far. When a segment’s physical document order is already guaranteed to match the requested sort order, that uncertainty disappears entirely: if you are scanning in descending timestamp order and have already gathered enough results, every remaining document in that segment is guaranteed to be older still, and therefore guaranteed not to belong in a “most recent” result set.

Why this matters most for “top N” style queries

Early termination’s benefit is concentrated specifically in queries asking for a bounded number of top results in sorted order, sometimes described as “top N” queries. A query that genuinely needs to examine every single matching document regardless, such as one computing an aggregate statistic across an entire result set, gains little or nothing from index sorting, since there is no early stopping point to reach; every matching document must be visited no matter how the data happens to be arranged physically.

Early termination and filters working together

Early termination becomes even more valuable when combined with filters that narrow down the candidate set further, such as a query for a specific vehicle’s most recent events. Because the physical order already guarantees the front of the segment holds the most recent overall documents, and a filter further narrows which of those are relevant, the combination can allow the search to stop remarkably early, having examined only a small handful of documents to fully satisfy a request that, in an unsorted index, would have required scanning a much larger share of the matching set.

Beyond early termination, index sorting has secondary effects on storage efficiency and on the ongoing cost of segment merging that are worth understanding in depth.

Locality improves compression

Many of Elasticsearch’s underlying storage structures, particularly the column-oriented doc values used for sorting, aggregations, and scripting, compress considerably better when similar values sit physically near one another. An unsorted segment might place a very small numeric value directly next to a very large one, purely by coincidence of arrival order, which compresses poorly. A sorted segment, by contrast, naturally clusters similar values together, since documents with nearby sort-field values end up physically adjacent, which in many cases meaningfully improves compression ratios for those underlying structures, reducing disk footprint and sometimes improving read performance as a pleasant side effect.

Segment merge cost with index sorting enabled

Every merge operation, sorted index or not, involves reading multiple existing segments and writing one combined new segment. With index sorting enabled, the merge process has the additional responsibility of interleaving documents from multiple already-sorted segments into one correctly and fully sorted output, which is somewhat more computationally involved than a simple, order-agnostic merge. This additional merge cost is an ongoing, recurring cost for the lifetime of the index, not a one-time setup cost, since merges continue happening in the background for as long as the index keeps receiving writes.

flowchart LR
  A["Segment 1
(sorted)"] --> M["Merge process:
interleave while
preserving sort order"]
  B["Segment 2
(sorted)"] --> M
  C["Segment 3
(sorted)"] --> M
  M --> D["New merged segment
(still fully sorted)"]

Interaction with the recommended larger-segment strategy for time-based data

Time-based workloads, such as logging and metrics indices, commonly benefit from strategies that favor fewer, larger, well-optimized segments over time, since older data is typically searched less frequently and can tolerate a heavier, less frequent optimization pass. Index sorting fits naturally into this broader strategy: a large, well-merged, sorted segment holding a long span of historical time-ordered data continues to provide the same early-termination benefits at search time, while consolidating the sorting-related merge overhead into fewer, larger, less frequent merge operations rather than many small, constant ones.

Why compression gains are not guaranteed for every field type

The compression improvement from better value locality is real but uneven across different kinds of fields. A numeric timestamp field, where nearby documents in sorted order genuinely have nearby, closely-spaced values, tends to compress noticeably better once physically clustered this way. A field holding highly varied, effectively random text or identifiers, by contrast, may see little to no compression benefit from index sorting, simply because there is no meaningful notion of “nearby values” for that kind of data to exploit. This means the storage-efficiency argument for index sorting is strongest specifically for numeric, date, and similarly ordered field types, and should not be assumed to automatically apply to every field an index happens to contain.

Merge policy interactions worth being aware of

Lucene’s merge policy, the logic deciding when and which segments to combine, continues to operate normally alongside index sorting, but every merge decision it makes now carries the additional, built-in requirement of producing a correctly sorted output. Teams that have tuned merge policy settings aggressively for other reasons, such as unusually large segment size targets, should re-validate those settings specifically under index sorting, since the added sorting overhead per merge can shift the balance of what previously felt like a reasonable merge policy configuration for an unsorted index.

Index sorting does not compose cleanly with every other Elasticsearch feature, and understanding these boundaries prevents painful surprises later.

Incompatibility with certain nested and parent-child structures

Certain advanced document relationship features, including deeply nested documents and parent-child style relationships, rely on their own internal assumptions about document ordering within a segment, assumptions that can conflict with an externally imposed index sort. As a result, index sorting has historically carried real restrictions or outright incompatibilities when combined with these features, and any team planning to use both together needs to verify current compatibility carefully before committing to that combination, since the interaction between these two areas has been an evolving part of Elasticsearch’s feature set.

Why index sorting cannot be changed after creation

Because the sort order is baked into the physical layout of every segment as it is written, and because every merge operation depends on all input segments already agreeing on that same order, there is no safe way to flip index sorting on, off, or to a different field for an index that already contains data. Doing so would require rewriting every existing segment from scratch to match the new order, which is precisely what reindexing into a new, correctly configured index accomplishes; there is no lighter-weight in-place alternative.

Relationship to time-series-oriented indexing strategies

Workloads built around continuously arriving, time-stamped data, such as logs and metrics, very naturally align with index sorting on a timestamp field, since the overwhelming majority of queries against such data ask for recent data first. This natural alignment is precisely why index sorting on time fields has become a standard, widely recommended technique specifically within logging- and metrics-oriented Elasticsearch deployments, more so than in workloads without such a clearly dominant temporal query pattern.

Deeper mechanics around how compound sorts behave, and how the search machinery decides whether early termination is safe to apply.

How a compound index sort interacts with a compound search sort

When an index is configured with a compound sort, such as first by category and then by timestamp within category, a search requesting the exact same compound sort, in the same order and directions, can take full advantage of early termination across both fields simultaneously. A search requesting only the first field of that compound sort, category alone, can still benefit from early termination on that first field, since a prefix of a satisfied compound order is itself still a valid, provable ordering guarantee. A search requesting a sort that does not match this configured order at all, however, cannot benefit from early termination, since the physical arrangement provides no relevant guarantee for an unrelated requested order.

How the search machinery decides whether the optimization is safe

Before applying early termination, the underlying search machinery has to verify, for each segment being searched, that the segment’s own recorded physical sort order genuinely matches, or is a compatible prefix of, the sort requested by the query. This verification is exactly why the benefit is automatic and requires no special syntax in the search request itself: as long as the index was configured with the right sort at creation time, any query that happens to ask for a matching sort receives the optimization transparently, without needing to explicitly request it.

Behavior across a mix of old and new segments

Because segments are immutable once written, and merges preserve sort order going forward, every segment belonging to a properly configured, sorted index maintains the same sort guarantee, whether it was written on day one or written this morning. This consistency is what makes the early-termination optimization reliably available across an index’s entire lifetime, rather than only for the newest data.

Index sorting is a genuine trade, not a strictly-better feature, and understanding both sides leads to better decisions.

When the trade is clearly worth making

The trade tends to be clearly worthwhile when an index serves a high volume of “most recent first” or similarly bounded, sorted queries against a field with an obvious, dominant, stable meaning, such as a timestamp in a logging or monitoring index, especially when that same field’s query pattern is expected to remain stable over the index’s lifetime.

When the trade is clearly not worth making

The trade tends to be a poor one for indices whose query patterns are highly varied, with no single dominant sort field, or for indices where write throughput is the primary bottleneck and search latency is comparatively unimportant, since in that situation the added indexing and merge overhead would be pure cost with little corresponding benefit.

Index sorting’s performance characteristics show up differently on the write side and the read side, and both deserve deliberate attention.

Indexing throughput impact

Because every segment build now involves sorting a batch of documents rather than simply writing them in arrival order, indexing throughput on a sorted index is generally somewhat lower than on an equivalent unsorted index, all else being equal. The magnitude of this impact depends heavily on batch sizes, the complexity of the sort key, and how frequently merges occur, but it is a real, measurable cost that should be benchmarked for a given workload rather than assumed away.

Search latency impact for matching queries

For queries whose requested sort matches the index’s configured sort, search latency can improve substantially, sometimes dramatically, particularly for “top N” queries against large historical data sets, since early termination allows the search to avoid examining the vast majority of matching documents entirely.

Scaling considerations for very high write-volume indices

Extremely high write-volume workloads, where indexing throughput is already the tightest bottleneck in the system, deserve particular caution before adding index sorting overhead on top, since even a modest percentage slowdown in raw indexing throughput can become operationally significant at very large scale. Careful benchmarking under representative production load, rather than relying on small-scale test results alone, is the right way to validate that the trade-off holds up at the volumes a given deployment actually needs to sustain.

Interaction with shard count and parallelism

Because index sorting overhead is applied independently within every shard, an index split across more shards distributes the additional sorting and merging work across more parallel indexing threads and more machines, which can partially offset the per-shard overhead at a cluster-wide throughput level, even though each individual shard is still doing the same relative amount of extra work per document. This means shard count and index sorting overhead are not entirely independent considerations, and a capacity planning exercise for a sorted index should account for both together rather than reasoning about each one purely in isolation.

Read-side scalability under heavy concurrent query load

Beyond single-query latency, the aggregate reduction in work per query that index sorting provides also has a scalability benefit under heavy concurrent load: a cluster serving many simultaneous “top N sorted” queries against a large sorted index does meaningfully less total work, summed across all those concurrent queries, than the same cluster would if every one of those queries had to scan a much larger share of matching documents individually. This aggregate effect can be the difference between a cluster comfortably absorbing a traffic spike and one that becomes saturated, particularly for dashboards or applications that issue this exact style of query at high concurrency.

Index sorting interacts with the broader reliability story of a cluster mainly through how it is consistently applied across shard copies.

Consistency across primary and replica shards

Because index sorting is an index-level setting rather than something configured independently per shard copy, every replica of a shard applies the exact same sort configuration as its primary, ensuring that promoting a replica to primary, for whatever reason, never changes the physical sort guarantees that searches depend on. This consistency is essential: if a replica somehow built its segments with a different sort order than its primary, search behavior and early-termination guarantees could differ unpredictably depending on which shard copy happened to serve a given request.

Recovery and reindexing considerations

Because sort settings cannot change after index creation, disaster-recovery and reindexing procedures for a sorted index need to explicitly account for recreating the index with the same sort configuration before restoring or replaying data into it, rather than assuming any newly created index will automatically inherit the same behavior as the one it replaces. Overlooking this detail during a recovery procedure would silently produce a working, but no longer sorted, replacement index.

Index sorting is not a security feature, but a few considerations are worth understanding for teams responsible for data protection.

Physical ordering does not expose additional data

Enabling index sorting changes the physical arrangement of documents within a segment, but it does not change what data any given user or role is authorized to see. Field-level and document-level security continue to be enforced exactly as they would on an unsorted index, since those protections operate at the level of what a query is allowed to request and return, entirely independent of the underlying physical storage order.

Sort field choice and inference risk

A subtle consideration worth being aware of is that choosing a sensitive field as the sort key, while not exposing that field’s actual values to unauthorized users, could in unusual, tightly constructed scenarios allow a sufficiently determined party to infer coarse ordering information indirectly, for example through carefully crafted queries that exploit early-termination timing differences. This is a narrow, largely theoretical concern for most workloads, but it is worth being deliberate about which fields are chosen as sort keys in unusually sensitive environments, favoring non-sensitive fields such as timestamps over fields that themselves carry sensitive meaning.

A well-configured index sort is largely invisible in day-to-day operation, but a handful of signals are worth watching to confirm it continues delivering the intended benefit.

Indexing throughput and latency

Because index sorting adds measurable overhead to indexing, tracking indexing throughput and latency before and after enabling it, or across sorted versus unsorted indices serving comparable workloads, is the most direct way to quantify its real-world cost in a given environment, rather than relying purely on generic expectations.

Search latency for representative queries

Tracking search latency specifically for the queries index sorting was intended to help, ideally the exact “top N sorted by X” style queries that motivated the decision in the first place, confirms whether the expected benefit is actually being realized in production, as opposed to only in a benchmark or test environment that may not fully represent real query patterns and real data volumes.

Watching for query-pattern drift over time

Because index sorting’s benefit depends entirely on the dominant query pattern remaining aligned with the chosen sort field, it is worth periodically revisiting actual query patterns against a sorted index over time, particularly as an application evolves, to confirm the original assumption that motivated the sort configuration still holds true, rather than discovering years later that the dominant query shape quietly shifted and the sort configuration stopped paying for itself.

Practical guidance distilled from how index sorting is used well, and used poorly, in real deployments.

A best practice around combining with time-based index rollover

Time-based workloads that already roll over into new indices periodically, such as daily or weekly logging indices, are a particularly natural fit for index sorting, since each newly created index in the rollover series can simply inherit the sort configuration from a shared index template, requiring no manual, per-index reconfiguration as the series continues to grow over time.

Concrete scenarios illustrate how index sorting’s benefits, and its costs, actually play out for real applications built on Elasticsearch.

Straightforward answers to the questions people most often ask once they first encounter index sorting.

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

Index sorting is a permanent, index-creation-time decision to physically arrange every document within every Lucene segment according to one or more chosen fields, rather than leaving them in arbitrary arrival order. Its entire value comes from a single mechanism, early termination, which lets a search stop scanning a segment early whenever the segment’s guaranteed physical order matches the order the search itself requested. This can turn certain “top N sorted” queries from expensive, full-scan operations into remarkably cheap ones, at the real, ongoing cost of additional work during every segment build and every subsequent merge. Understanding this trade precisely, and validating it against a workload’s actual, dominant query pattern before committing to it, is the difference between index sorting delivering exactly the benefit it promises and it silently becoming pure overhead.