Evidence ledger
One row per claim in The object store became the quorum: ten years of Elasticsearch, read from its own repository: who published it, what grade it carries, when it was written, when the link was last checked, and the quote or figure it rests on. Nothing in the guide is cited from memory, so anything not in this table is not in the guide.
Field guide: The object store became the quorum: ten years of Elasticsearch, read from its own repository Research date: 2026-10-12. Every URL below was fetched or resolved in this session on 2026-10-12.
Hunt constraint, stated up front
This session's egress policy permitted github.com git reads (anonymous clone/fetch of public
repositories), raw.githubusercontent.com, gitlab.com and the package registries, and refused
every engineering-blog, conference, preprint and digital-library host tried: elastic.co,
opensearch.org, aws.amazon.com, dl.acm.org, usenix.org, arxiv.org, medium.com,
docs.aws.amazon.com (CONNECT returned 403 at the egress proxy). GitHub's HTML and REST API are
also refused for repositories not attached to this session, so issue threads, pull-request
discussions and security advisories were unreachable.
The guide is therefore built from two complete git histories (elastic/elasticsearch, 106,974
commits to 2026-10-12; opensearch-project/OpenSearch, 61,541 commits to 2026-10-12), the design
documents and release notes committed inside those repositories, and source files fetched from
raw.githubusercontent.com at pinned commits or tags. There is no blog, talk or paper tier
in this guide, and that absence is recorded in the page rather than papered over. Two primary
accounts are named inside the repository and were not fetched: Elastic's serverless architecture
blog and the SoCC'25 paper Elasticsearch on the cloud: a stateless architecture
(doi 10.1145/3772052.3772245). Any reader with open egress should start there.
Commit SHAs were read from a local clone; github.com/elastic/elasticsearch/commit/<sha> and
github.com/opensearch-project/OpenSearch/commit/<sha> URLs in the page are the human-readable
addresses of commits verified locally, not pages fetched through the proxy.
Ledger
| # | Org | Title | Tier | Published | Checked | URL | Claim taken from it | Supporting quote or figure |
|---|---|---|---|---|---|---|---|---|
| 1 | Elastic | docs/internal/s3-object-store-requirements.md, Registers |
adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | Cluster coordination in stateless Elasticsearch rests on a linearizable register in the object store | "Register operations are the foundation of distributed coordination across Elasticsearch... For stateless Elasticsearch, the CAS register is the mechanism for master election and cluster lease management... Without linearizable CAS, split-brain scenarios or duplicate masters are possible." |
| 2 | Elastic | same document, Registers, implementation paths | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | There are exactly two CAS paths, and the fallback is named for its unsafety | "Path 1 — Conditional writes (preferred)... Path 2 — Multipart upload consensus protocol... Note: this path does NOT provide failIfAlreadyExists protection on regular blob writes — the setting is named \"unsafely\" for this reason." |
| 3 | Elastic | same document, Read-After-Write Consistency | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | The hot path assumes immediate cross-node consistency with no retry for data blobs | "after writeBlobAtomic uploads a commit, a different node's shard recovery process immediately lists and reads blobs to discover new commits — there is no polling or retry logic for data blobs. The code assumes immediate consistency throughout" |
| 4 | Elastic | same document, Blob Listing Consistency | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | A missing blob in a listing is silent data loss or silent leakage, depending on which listing | "A missing blob in a listing during recovery means a commit is invisible and the shard operates on stale data; a missing blob in a GC listing means stale data accumulates indefinitely." |
| 5 | Elastic | same document, Server-Side Copy | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | Resharding is implemented as a server-side copy inside the object store | "ObjectStoreService uses copyBlob during shard resharding (splitting/merging) to efficiently copy commit files between shard containers without transferring data through the node." |
| 6 | Elastic | same document, multipart limits | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/s3-object-store-requirements.md | The store's own limits become the architecture's limits | "Part minimum size 5 MB, max 10,000 parts, max object 5 TB"; single upload threshold "defaults to 100 MB"; listing limit "1000 for S3" |
| 7 | Elastic | docs/internal/DistributedArchitectureGuide.md, Stateless Roles |
adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | Stateless replaces the data roles with index and search roles and makes local disk a cache | "data is persisted in a shared object storage and nodes' disk is only used as a cache layer. The data (and data tier) roles are disabled in favor of two new roles: index... search"; "Splitting the write path (index nodes) from the read path (search nodes) is what lets read and write capacity scale horizontally and independently." |
| 8 | Elastic | same guide, Serverless Elections | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | In the stateless deployment the voting quorum is one node and liveness is a blob heartbeat | "the master uses a single node voting configuration with only itself... Committing and publishing a new cluster state therefore only requires the master's own acknowledgment... the AtomicRegisterPreVoteCollector solely checks the latest heartbeat from the blob store and starts the election if it's older than the configured threshold (default 30 seconds). To become master, the candidate node will atomically override the current term in the blob store via a CAS operation." |
| 9 | Elastic | same guide, Serverless Elections, consistency gate | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | A write is fenced by comparing local cluster state against the authoritative blob before the ack | "Before a node acks a translog upload it verifies that its local cluster state is consistent with the authoritative blob... blocking writes if cluster membership has changed and the node's local state has not yet caught up. This prevents a node that has fallen behind on cluster-state updates from durably acknowledging writes it should no longer be handling." |
| 10 | Elastic | same guide, Indexing / CRUD | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | In the stateless deployment there is no replication at all; durability is delegated | "in serverless Elasticsearch, there is no replication process needed. The same reliability and fault tolerance are instead achieved by uploading the translog to a blob store and relying on the store's durability and fault tolerance guarantees. On an index node the TranslogReplicator batches operations into a node-level NodeTranslogBuffer" |
| 11 | Elastic | same guide, Primary Terms & Sequence Numbers | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | Every operation carries a name and a term, and the term settles conflicts | "Every successful index, update, or delete operation on a shard is tagged with a sequence number (seq_no) and a primary term... If two copies ever share the same _seq_no (for example after a primary promotion), the copy with the higher primary term wins." |
| 12 | Elastic | same guide, Translog, Acknowledging writes | adr | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/internal/DistributedArchitectureGuide.md | In the stateful engine the durability boundary is a local fsync, amortised across a batch | "The translog is always persisted and fsync'ed on disk before acknowledging writes back to the user"; "This process involves multiple writes to the translog before the next fsync(), and this is done so that we amortize the cost of the translog's fsync() operations across all writes." |
| 13 | Elastic | docs/release-notes/known-issues.md, 9.5.0-9.5.2 |
postmortem | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/release-notes/known-issues.md | A backpressure path let the primary process bulk items without replicating them, diverging replicas | "A bulk indexing operation which is being processed on the node holding the primary shard exactly when this node crosses the indexing pressure limit can process some of the bulk items on the primary shard without replicating them, causing the contents of any replicas to diverge from those of the primary... The divergence blocks shards from trimming their translog, consuming excessive disk space, and can also cause very long-running recoveries"; "introduced in #147151, released in Elasticsearch v9.5.0, and is fixed in #158235, released in Elasticsearch v9.5.3" |
| 14 | Elastic | docs/release-notes/known-issues.md, 9.5.0 / 9.5.1 |
postmortem | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/release-notes/known-issues.md | The storage-saving index modes returned false-positive matches through a Lucene scoring defect | "Boolean queries containing a must, filter, or should clause, along with a must_not clause, on fields with disabled indexing can return false-positive matches... TSDB and columnar indices and data streams are affected, since they disable indexing on all fields by default"; full fix "upgrades Elasticsearch to Lucene 10.5.1 (apache/lucene#16450), is included in 9.5.2" |
| 15 | Elastic | docs/release-notes/known-issues.md, 9.2.4 |
postmortem | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/release-notes/known-issues.md | A minor-version upgrade could leave a node unable to parse its own persisted cluster state | "Upgrading from 9.1.10 to 9.2.4 may cause the following error: fatal exception while booting Elasticsearch... Caused by: org.elasticsearch.gateway.CorruptStateException: ... failed to parse field [nodes]" |
| 16 | Elastic | docs/release-notes/changelog-bundles/9.2.0.yml, highlight |
vendor | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/release-notes/changelog-bundles/9.2.0.yml | Before 9.2.0 an unconditional overwrite could corrupt a snapshot repository | "Earlier versions of Elasticsearch had a small risk of inadvertently overwriting an object in an AWS S3 snapshot repository which, if it happened, might corrupt the repository contents. From version 9.2.0 onwards, Elasticsearch uses S3's conditional write feature to prevent this corruption." |
| 17 | Elastic | docs/release-notes/changelog-bundles/9.3.0.yml, PR 139228 |
vendor | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/release-notes/changelog-bundles/9.3.0.yml | The register CAS switched to conditional writes in 9.3.0 | entry: "pr: 139228 / summary: S3 compareAndExchange using conditional writes / area: Snapshot/Restore / type: enhancement" |
| 18 | Elastic | modules/repository-s3/.../S3BlobContainer.java, ensureOtherUploadsComplete |
source | tag v9.3.0 | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v9.3.0/modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3BlobContainer.java | The fallback CAS protocol is acknowledged in code as impossible in theory and adequate in practice | "the one with the first upload ID immediately tries to cancel the competing updates in order to make progress, but the ones with greater upload IDs wait based on their position... In theory this whole thing is provably impossible anyway [1] but in practice it'll eventually work with sufficient retries. [1] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. 1985. Impossibility of distributed consensus with one faulty process." |
| 19 | Elastic | same file, getUploadIndex |
source | tag v9.3.0 | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v9.3.0/modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3BlobContainer.java | The fallback protocol reads the store's clock and warns when it disagrees with the node's | log message: "compare-and-exchange of blob [{}:{}] was initiated at [{}={}] which deviates from local node epoch time [{}] by more than the warn threshold of [{}ms]" |
| 20 | Elastic | modules/repository-s3/.../S3Repository.java |
source | tag v9.3.0 | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v9.3.0/modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3Repository.java | Running against a store without conditional writes is now a logged corruption risk | setting unsafely_incompatible_with_s3_conditional_writes defaults to false; warning: "repository [{}] is configured to unsafely avoid conditional writes which may lead to repository corruption; to resolve this warning, upgrade your storage to a system that is fully compatible with AWS S3" |
| 21 | Elastic | commit 05ef24f05, "Mark S3 repo settings for removal (#156912)" | source | 2026-08-18 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/05ef24f05 | The escape hatch for non-conforming stores was deprecated on arrival and is scheduled for removal | "was introduced as a temporary workaround to allow users a little more time to upgrade their S3-compatible storage... It was documented as deprecated as soon as it was introduced, but it lacks the Deprecated property"; "add @UpdateForV10 annotations on the S3 repository settings scheduled for removal in the next major release" |
| 22 | Elastic | commit 49d5cd7f2, "S3 compare-and-exchange implementation (#94150)" | source | 2023-02-28 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/49d5cd7f2 | The object-store register shipped in February 2023, before conditional writes existed | commit subject and date as published in the repository history |
| 23 | Elastic | commit 2074dc4ea, "S3 compareAndExchange using conditional writes (#139228)" | source | 2025-12-15 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/2074dc4ea | The preferred CAS path arrived 2 years 9.5 months after the fallback | commit subject and date as published in the repository history |
| 24 | Elastic | commit da214475a, "Extract AtomicRegisterPreVoteCollector and StoreHeartbeatService to production (#95296)" | source | 2023-04-17 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/da214475a | Blob-store heartbeat leadership moved from test scaffolding into production code in April 2023 | commit subject and date; preceded by 3416ce0df "Stand down as leader on heartbeat failure (#94822)", 2023-03-28 |
| 25 | Elastic | commit 3aeeb4584, "Sync translog to object before acking write (elastic/elasticsearch-serverless#223)" | source | 2023-04-04 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/3aeeb4584 | The durability boundary moved from local fsync to an object-store upload | commit subject and date, migrated from the private serverless repository |
| 26 | Elastic | commit b715087a5, "Ensure stale indexing shard does not Ack write (elastic/elasticsearch-serverless#628)" | source | 2023-08-08 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/b715087a5 | Fencing a displaced writer was a defect found four months after the durability move | commit subject and date, migrated from the private serverless repository |
| 27 | Elastic | commit b40e7eb23, "Migrate stateless modules with full file history" | adr | 2026-04-29 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/b40e7eb23 | In April 2026 the private serverless fork was merged into the public repository, history intact, under the Elastic License | "Source: elasticsearch-serverless (branch: main) Target: elasticsearch/x-pack/plugin/, x-pack/test/, and x-pack/qa/"; "This migration preserves full git log --follow history by using a two-step rename strategy"; "Updated license headers to Elastic License 2.0"; "Fork commit: 3158274767d"; modules listed: stateless, stateless-health-shards-availability, stateless-master-failover, stateless-no-wait-for-active-shards, secure-settings, stateless-sigterm |
| 28 | Elastic | commit 6caac0157, "Remove extra modules/files that are out of scope for this migration" | source | 2026-04-23 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/6caac0157 | Part of the stateless code stayed serverless-only, so the public plugin is a subset | "These modules/files were brought in by git-filter-repo path renaming... but are not part of the modules-self-managed/ migration scope"; removed files include ServerlessStatelessPlugin.java, TransportUpdateSplitStateAction.java |
| 29 | Elastic | commit e3f86aa0d, "Add stateless skeleton project" | source | 2022-09-28 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/e3f86aa0d | The stateless project began in September 2022 in the private fork | commit subject and date, earliest stateless commit in the merged history |
| 30 | Elastic | commit 708c06896, "Explain why Elasticsearch doesn't support incremental resharding. (#29082)" | adr | 2018-03-16 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/708c06896 | In 2018 the project documented resharding as economically impossible, because the unit of storage is a local Lucene index | "Elasticsearch's unit of storage, shards, are Lucene indices. Because of their search-oriented data structure, taking a significant portion of a Lucene index, be it only 5% of documents, deleting them and indexing them on another shard typically comes with a much higher cost than with a key-value store... this allows Elasticsearch to perform the split locally... as well as using hard links for efficient file copying." |
| 31 | Elastic | commit b364cf54b, "Introduce Primary Terms"; 5fb0f9a88, "Add Sequence Numbers and enforce Primary Terms" | source | 2015-10-09; 2015-11-03 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/b364cf54b | The naming scheme that later made fencing possible was added in late 2015 | commit subjects and dates as published in the repository history |
| 32 | Elastic | commit 484432592, "Introduced Global checkpoints for Sequence Numbers (#15485)" | source | 2016-06-06 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/484432592 | The replication safety line was added in mid-2016 | commit subject and date |
| 33 | Elastic | commit ac84879a7, "Use soft deletes to maintain doc history (#29549)"; c0f8c8917, "Introduce shard history retention leases (#37167)" | source | 2018-04-19; 2019-01-07 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/c0f8c8917 | History retention became an explicit, leased resource in 2018-2019 | commit subjects and dates |
| 34 | Elastic | commit 2176184db, "[Zen2] Introduce gossip-like discovery of master nodes (#32246)"; 785b6e824, "Zen2: Cluster state publication pipeline (#32584)" | source | 2018-08-06; 2018-08-07 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/2176184db | The quorum-based coordination layer was built through 2018 and shipped in 7.0 (tag v7.0.0, 2019-04-10) | commit subjects and dates; tag date from the repository |
| 35 | Elastic | commit 50f4a0b77, "Add partial searchable snapshot support for a frozen tier (#68509)" | source | 2021-02-05 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/50f4a0b77 | The first production tier whose disk was only a partial cache shipped in early 2021 | commit subject and date; related: 1a432a26d "Only allocate partial shards to nodes with cache (#69904)", 2021-03-04 |
| 36 | Elastic | commit 654e85e39, "Feature flag for super thin hollow indexing shards"; 9325e5ca9, "Support recovering hollow shards with a hollow engine" | source | 2024-12-06; 2025-01-08 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/654e85e39 | By the end of 2024 an idle index shard could be evicted from compute entirely and recovered from the store | commit subjects and dates; companion c38e915ab "Is shard hollowable based on TTL and permits", 2024-12-11 |
| 37 | Elastic | commit fa0925518, "Online prewarming service interface docs and usage in SearchService (#126561)" | source | 2025-04-11 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/fa0925518 | Cache warming became a first-class service, which is the latency cost of the architecture made explicit | commit subject and date; companion 93c893a76 "Search online prewarming implementation for serverless", 2025-05-21 |
| 38 | Elastic | docs/reference/.../miscellaneous-cluster-settings.md |
vendor | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/docs/reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md | A node whose data lives in the object store is allowed three times the shards | "The cluster shard limit defaults to 1000 shards per non-frozen data node for normal (non-frozen) indices and 3000 shards per frozen data node for frozen indices." |
| 39 | Elastic | muted-tests.yml |
source | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/muted-tests.yml | The merged fork brought measurable test instability with it | 225 class: entries in the file, of which 31 lines name a stateless test or package (counted 2026-10-12) |
| 40 | Elastic | x-pack/plugin/stateless/.../StatelessPlugin.java |
source | repo, main @b2f4a538f | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/b2f4a538f/x-pack/plugin/stateless/src/main/java/org/elasticsearch/xpack/stateless/StatelessPlugin.java | The architecture is now public source but not open source | file header: "Licensed under the Elastic License 2.0; you may not use this file except in compliance with the Elastic License 2.0." |
| 41 | Elastic | LICENSE.txt at tag v7.10.2 |
source | tag v7.10.2 (2021-01) | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v7.10.2/LICENSE.txt | Up to 7.10 the repository was Apache-2.0 based | "Source code in this repository is covered by one of three licenses: (i) the Apache License 2.0 (ii) an Apache License 2.0 compatible license" |
| 42 | Elastic | LICENSE.txt at tag v7.11.0 |
source | tag v7.11.0, 2021-02-10 | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v7.11.0/LICENSE.txt | From 7.11 the default licence became SSPL/Elastic License | "Source code in this repository is covered by (i) a dual license under the Server Side Public License, v 1 and the Elastic License 2.0" |
| 43 | Elastic | LICENSE.txt at tag v8.16.0 |
source | tag v8.16.0, 2024-11-08 | 2026-10-12 | https://raw.githubusercontent.com/elastic/elasticsearch/v8.16.0/LICENSE.txt | From 8.16 AGPL-3.0 was added as a third option | "Source code in this repository is covered by (i) a triple license under the \"GNU Affero General Public License v3.0 only\"" |
| 44 | Elastic | commit f11ef4408, "Introduce logs index mode as Tech Preview (#108896)" |
source | 2024-05-30 | 2026-10-12 | https://github.com/elastic/elasticsearch/commit/f11ef4408 | The storage-cost work that later produced the false-positive defect began in May 2024 | commit subject and date |
| 45 | Elastic | elastic/elasticsearch git history | source | cloned 2026-10-12 | 2026-10-12 | https://github.com/elastic/elasticsearch | Derived counts: 106,974 commits to 2026-10-12; commits whose message names a stateless change per year: 14 (2022), 174 (2023), 173 (2024), 104 (2025), 505 (2026 to 2026-10-12); 2,090 commits reference elastic/elasticsearch-serverless# |
git rev-list --count HEAD; git log --grep=stateless -i bucketed by --since/--until; git log --grep='elasticsearch-serverless#' \| wc -l |
| 46 | OpenSearch | commit ee7b73197, "Adds the replication type index setting, alongside a formal notion of feature flags (#3037)" | source | 2022-04-25 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/ee7b73197 | The fork's answer began with segment replication, an index-level setting, in April 2022 | commit subject and date as published in the repository history |
| 47 | OpenSearch | commit fb1375987, "[Remote Store] Upload segments to remote store post refresh (#3460)" | source | 2022-06-10 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/fb1375987 | The fork moved segments to object storage two months later, keeping shards on data nodes | commit subject and date |
| 48 | OpenSearch | commit 57a4aedb0, "[Remote Store] Change behaviour in replica recovery for remote translog enabled indices (#4318)" | source | 2022-09-17 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/57a4aedb0 | Remote translog followed, making the store the recovery source | commit subject and date |
| 49 | OpenSearch | commit d375e4cfe, "[Remote state] Integrate remote cluster state in publish/commit flow (#9665)" | source | 2023-09-04 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/d375e4cfe | The fork put cluster state in the store as a publication and recovery aid, not as an election register | commit subject and date |
| 50 | OpenSearch | commit 98da9b425, "Add object-store fencing token for remote store primary term validation (#22774)" | adr | 2026-09-01 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/98da9b425 | Four years later the fork moved fencing to a CAS object too, for the same reason, and said what the replica-based scheme had cost | "Segment-replication remote-store indices currently rely on a replica to fence a stale primary... That makes at least one replica a safety requirement, which blocks zero-replica remote-backed indices from recovering automatically on node loss - the new primary would begin acknowledging seconds after node-left while the old one is very likely still alive and unaware. Make the object store the authority instead. Each shard keeps one small mutable object per primary term in the translog repository, fence__ |
| 51 | OpenSearch | commit ee6052b64, "Implement Directory and IndexInput layers for WritableWarm tiered storage (#21178)"; bf7bfedc0, "Add module wiring and integration tests for WritableWarm tiered storage (#21427)" | source | 2026-04-17; 2026-05-07 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch/commit/ee6052b64 | The fork's compute/storage separation arrives as a tier with a file cache, not as a node-role split | commit subjects and dates |
| 52 | OpenSearch | opensearch-project/OpenSearch git history | source | cloned 2026-10-12 | 2026-10-12 | https://github.com/opensearch-project/OpenSearch | Derived: 61,541 commits to 2026-10-12; no commit message in the history mentions conditional writes or compare-and-swap before 98da9b425 (2026-09-01) | git rev-list --count HEAD; git log --grep='conditional write' -i, git log --grep='compare-and' -i each return that single commit |
Named but not fetched
| Artefact | Where it is named | Why it is not in the ledger |
|---|---|---|
| Elasticsearch on the cloud: a stateless architecture, SoCC '25, doi 10.1145/3772052.3772245 | docs/internal/DistributedArchitectureGuide.md, Stateless Roles |
dl.acm.org refused by this session's egress policy. It is the one peer-reviewed account of this architecture and a reader with open egress should read it before trusting any reconstruction here. |
| Elastic serverless architecture blog; "Thin indexing shards in Elasticsearch serverless" (search-labs) | same guide, Stateless Roles and Indexing / CRUD | elastic.co refused. Contains the two-tier architecture diagram and, by the guide's description, the indexing-shard detail. |
| apache/lucene#16450 | docs/release-notes/known-issues.md |
GitHub HTML and API refused; the defect is cited here only through Elastic's own description of it. |
| Elastic and OpenSearch issue threads, pull-request discussions, security advisories | — | GitHub HTML and REST API refused for unattached repositories. Rejected and closed-unmerged pull requests, normally the best material in a dig of this kind, are therefore absent. |