{
  "slug": "sqlite-serialization",
  "term": "SQLite serialization",
  "aliases": [
    "sqlite3_serialize",
    "SQLite database image"
  ],
  "definition": "SQLite serialization exports a selected database on one connection as a contiguous database-file image.",
  "note": "The API selects a connection and a named database. This is a binary database image, not an SQL text dump or the transaction-isolation property called serializability. The ordinary call allocates a copy; NOCOPY can return NULL when no contiguous representation exists. [serialize]\n\nIn Hesela's controlled SQLite 3.45.1 and 3.54.1 runs, a writer exported changed rows before rolling back. The detached image retained values never committed in the source database and passed integrity_check. A separate private-cache reader and a backup reaching SQLITE_DONE through that reader retained the committed base rows. These are native fixture observations, not failure-rate estimates. [evidence] [isolation]\n\nSuccessful sqlite3_deserialize setup is a separate check from successful queries. In each capture, all nine WAL-header images returned SQLITE_OK from setup but SQLITE_CANTOPEN on use. Setting input-buffer bytes 18 and 19 to 0x01 before deserialization enabled reads, as documented. This detached-buffer conversion does not establish commit provenance or reconstruct omitted WAL content; never treat it as live-database repair. [deserialize] [evidence]\n\nA pinned WAL reader can export an older committed view after another connection commits. Validate the intended source state, actual recovery-path queries and application expectations separately. Structural consistency and byte identity do not establish freshness. [isolation] [analysis]",
  "related": [
    "sqlite-online-backup",
    "sqlite-transaction-state",
    "sqlite-wal-end-mark",
    "physical-backup",
    "logical-backup",
    "serializability",
    "backup-verification",
    "restore-test"
  ],
  "citations": [
    {
      "id": "serialize",
      "title": "SQLite C API: Serialize a database, connection/schema scope and copy flags",
      "url": "https://sqlite.org/c3ref/serialize.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "deserialize",
      "title": "SQLite C API: Deserialize a database, WAL-mode input restriction",
      "url": "https://sqlite.org/c3ref/deserialize.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "isolation",
      "title": "SQLite: isolation between connections and retained WAL snapshots",
      "url": "https://sqlite.org/isolation.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "evidence",
      "title": "Hesela: frozen two-build serialization observations and source identities",
      "url": "https://hesela.dev/research/sqlite-serialize-provenance/summary.json",
      "accessed": "2026-11-03"
    },
    {
      "id": "analysis",
      "title": "Hesela: serialized images, source commit provenance and recovery acceptance",
      "url": "https://hesela.com/analyses/backup-verification-is-not-a-restore-test/#sqlite-serialization",
      "accessed": "2026-11-03"
    }
  ],
  "provenance": [
    "Controlled native C API calls with private caches, explicit transaction ordering and disabled writer cache spilling; 16 image origins per build, two original captures each, three restore paths. No process-crash, power-loss or production-incidence inference."
  ],
  "status": "shipping",
  "advantages": [],
  "limitations": [
    "The two tested builds have different compile configurations; their comparison does not isolate a version effect.",
    "Shared-cache read_uncommitted behavior and arbitrary malformed input were not tested."
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-11-03"
}