> > > SpecAdr009LedgerStorageBackendStrategy

ADR-009: Ledger Storage Backend Strategy

Status

Accepted

Context

The ledger is SOTER's immutable, bitemporal organizational fact record.

Several storage technologies were evaluated, including EventStoreDB, Datomic, immudb, and Google Trillian. None of them directly defines SOTER's full contract for save-first recording, bitemporal metadata, correction chains, local-first development, and protocol portability.

Decision

SOTER defines Ledger as a protocol layer and delegates physical persistence to pluggable storage adapters.

Ledger Protocol Layer
  -> Files + SQLite adapter
  -> PostgreSQL adapter
  -> Future transparency / compliance adapters

The protocol owns fact schema, canonicalization, hash calculation, and compensation semantics. Storage adapters own persistence mechanics.

Rationale

The ledger should not become synonymous with one database product. SOTER needs a local, inspectable MVP backend and a path to production storage without changing the fact protocol.

Consequences

Positive

File + SQLite supports local development and audit inspection.
PostgreSQL can support later concurrent enterprise usage.
Specialized tamper-evident backends can be added without changing SOTER semantics.

Negative

Adapter boundaries must be tested carefully.
Protocol evolution must consider multiple storage implementations.

Neutral or Operational

Canonicalization must prevent cosmetic formatting changes from changing fact identity.
Logical compensation uses corrects references.

Alternatives Considered

One Fixed Database Backend

Rejected because it would couple the protocol to storage and weaken portability.

Existing Event Store as the Protocol

Rejected because existing event stores do not define SOTER's fact envelope and interpretation boundaries.

Migration or Adoption

The MVP should use files plus SQLite. Production work may introduce PostgreSQL as another adapter without changing the canonical fact contract.