{
  "status": "shipping",
  "advantages": [
    {
      "text": "A transaction begun after another completes cannot be serialized before it.",
      "citationIds": [
        "herlihy-wing"
      ]
    }
  ],
  "limitations": [
    {
      "text": "The guarantee covers the specified transaction scope, not arbitrary separate requests or external side effects.",
      "citationIds": [
        "herlihy-wing",
        "etcd-guarantees"
      ]
    },
    {
      "text": "Durability and recovery after failures require separate guarantees.",
      "citationIds": [
        "etcd-guarantees"
      ]
    }
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-10-30",
  "slug": "strict-serializability",
  "term": "Strict serializability",
  "aliases": [
    "Strictly serializable isolation"
  ],
  "definition": "Strict serializability requires committed transactions to be equivalent to a serial execution that preserves real-time precedence between non-overlapping transactions.",
  "note": "Serializability alone omits real-time precedence. Linearizability is the special case of one operation on one object per transaction. Separate reads do not automatically constitute a transaction. The property constrains committed histories, not observations from aborted transactions. [herlihy-wing]\n\nA transaction completed before another begins must precede it in the serial order. The companion analysis illustrates the difference using two records, not a database experiment. [herlihy-wing]\n\nIn etcd v3.6, RangeRequest.serializable=true selects member-local reads that may lag consensus. Selecting an explicit historical revision asks a different question from reading current state; neither option turns an arbitrary client sequence into a transaction. [etcd-reference]\n\netcd documents durability separately. Its watches are revision-ordered but not linearizable, and a request timeout can leave the outcome unknown. Ordering does not imply a watch delivery deadline or safe repetition of a non-idempotent operation. [etcd-guarantees]",
  "related": [
    "linearizability",
    "serializability",
    "serializable-snapshot-isolation"
  ],
  "citations": [
    {
      "id": "herlihy-wing",
      "title": "Herlihy and Wing. Linearizability: A Correctness Condition for Concurrent Objects. ACM TOPLAS 12(3), 1990, sections 2.2 and 3.3 (p. 473).",
      "url": "https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf",
      "accessed": "2026-10-30"
    },
    {
      "id": "etcd-guarantees",
      "title": "etcd v3.6 API guarantees: Strict serializability, Durability, Watch APIs and Operation completed.",
      "url": "https://etcd.io/docs/v3.6/learning/api_guarantees/",
      "accessed": "2026-10-30"
    },
    {
      "id": "etcd-reference",
      "title": "etcd v3.6 API reference: RangeRequest revision and serializable fields; TxnRequest.",
      "url": "https://etcd.io/docs/v3.6/dev-guide/api_reference_v3/",
      "accessed": "2026-10-30"
    },
    {
      "id": "hesela-consistency",
      "title": "Hesela: Storage consistency, ordering and transaction scope.",
      "url": "https://hesela.com/analyses/storage-consistency-ordering/",
      "accessed": "2026-10-30"
    }
  ],
  "provenance": [
    "Definition and illustrative history derived from Herlihy and Wing sections 2.2 and 3.3; no benchmark or empirical consistency test.",
    "etcd implementation claims are scoped to v3.6 documentation; an overlapping linearizable read need not include every write completed before its response."
  ]
}