{
  "slug": "sorted-run",
  "term": "Sorted run",
  "aliases": [
    "LSM sorted run"
  ],
  "definition": "In an LSM-tree, a disk-resident sorted run is a logical sequence of key-ordered records stored in one immutable SST file or range-partitioned across multiple SST files.",
  "note": "Layout: RocksDB's nonzero leveled levels each form one run, while L0 can contain overlapping runs. Individual files being sorted does not make an arbitrary overlapping collection one globally ordered run. [rocks-levels]\n\nCounting: The documented Universal-compaction example has three one-file L0 runs, a four-file L4 run and an eight-file L5 run: five runs across fifteen files. This is a layout illustration, not a benchmark or a required configuration. [rocks-universal]\n\nVisibility: Sorted records are not necessarily only the latest values visible to a reader. LevelDB retains deletion markers to hide older values and merges tables during compaction. Ordering, visibility and reclamation are separate concerns. [leveldb]",
  "status": "shipping",
  "advantages": [],
  "limitations": [
    {
      "text": "Run count is not a physical-read count: key-range selection, filters, caching and the query type affect which data must actually be read.",
      "citationIds": [
        "compaction-design",
        "rocks-tuning"
      ]
    },
    {
      "text": "A Bloom-negative probe can still require filter metadata. Measure key-present/key-absent mix and metadata-cache residency; the cited study's mixed-query latency is an experiment-specific result, not a consequence of run count alone.",
      "citationIds": [
        "compaction-design"
      ]
    }
  ],
  "related": [
    "lsm-tree",
    "sstable",
    "leveled-compaction",
    "tiered-compaction"
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-10-25",
  "citations": [
    {
      "id": "rocks-levels",
      "title": "RocksDB project. Leveled Compaction: Structure of the files.",
      "url": "https://github.com/facebook/rocksdb/wiki/Leveled-Compaction",
      "accessed": "2026-10-25"
    },
    {
      "id": "rocks-universal",
      "title": "RocksDB project. Universal Compaction: Overview and Data Layout / Sorted Runs.",
      "url": "https://github.com/facebook/rocksdb/wiki/Universal-Compaction",
      "accessed": "2026-10-25"
    },
    {
      "id": "leveldb",
      "title": "LevelDB 1.23 implementation note: Sorted tables and Compactions.",
      "url": "https://github.com/google/leveldb/blob/1.23/doc/impl.md",
      "accessed": "2026-10-25"
    },
    {
      "id": "compaction-design",
      "title": "Sarkar et al. Constructing and Analyzing the LSM Compaction Design Space. PVLDB 14(11), 2216-2229 (2021), sections 2 and 5.1.2. DOI: 10.14778/3476249.3476274.",
      "url": "https://www.vldb.org/pvldb/vol14/p2216-sarkar.pdf",
      "accessed": "2026-10-25"
    },
    {
      "id": "hesela",
      "title": "Hesela: Bloom filters, compaction and lookup measurement boundaries.",
      "url": "https://hesela.com/analyses/bloom-filters-lsm-read-cost/#compaction",
      "accessed": "2026-10-25"
    },
    {
      "id": "rocks-tuning",
      "title": "RocksDB project. Tuning Guide: Amplification factors and cached versus physical reads.",
      "url": "https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide",
      "accessed": "2026-10-25"
    }
  ],
  "provenance": [
    "The term describes a logical storage unit, not a specific on-disk format. RocksDB layout examples do not define every LSM implementation. [rocks-levels] [rocks-universal]"
  ]
}