Software sovereignty: own the platform your regulated system runs on
Practice · Bare Metal Software
Software sovereignty means every system boundary your regulated software depends on — the database, the replication mechanism, the deployment target — is one your own team controls and can operate without a vendor's continued cooperation. SQLite in WAL mode with Litestream replicating to object storage is sovereignty's concrete shape for the data layer: no managed-database vendor, no proprietary export format, a restore procedure your own team can run.
What does software sovereignty mean for a regulated system?
Software sovereignty means every system boundary your software depends on is one your own team controls and can operate without a vendor's continued cooperation. For the data layer, SQLite in WAL mode with Litestream replicating to object storage is its concrete shape.
The disappearance test
Chapter 6 of the fieldbook frames sovereignty as a concrete test, not a philosophy: if a vendor disappeared tomorrow, could the system keep running? A managed database service that disappeared would take your data layer with it unless you'd already exported everything. A SQLite file on disk, replicated by an open-source tool you run yourself, passes the test by construction — the data already lives in a format and location you control.
SQLite + WAL + Litestream: sovereignty's concrete shape
This repository's own database layer (src/db.rs) is the
pattern applied directly: SQLite opened in WAL (write-ahead log)
mode with synchronous=NORMAL — the durability level
that survives an application crash and loses at most the last commit after
an OS crash, without FULL's fsync-per-write cost. Litestream
continuously replicates the WAL to object storage, so a restore doesn't
depend on a managed database vendor's backup product — it depends on a
file format and an open-source replication tool your own team can inspect,
run, and — critically — test the restore of, which is the actual
proof of sovereignty a vendor's SLA can't substitute for.
The Growth Ladder: climb on evidence, never on speculation
Sovereignty doesn't mean refusing to scale — it means scaling on a rule,
not a guess. This repository's ARCHITECTURE.md §5.5 Growth
Ladder (the fieldbook's own Chapter 10, p.71, folded in as supplementary
per-feature triggers) states the authoritative rungs:
| Rung | Topology | Climb when |
|---|---|---|
| 0 — Launch | Single VPS; SQLite + WAL; Litestream to object storage; one process | Starting rung |
| 1 — Split stores | Separate SQLite DBs for telemetry vs. CRM/GTM | >200 concurrent active users; or SQLITE_BUSY >0.1% of writes |
| 2 — PostgreSQL (single node) | CRM/GTM on self-hosted PostgreSQL | CRM DB >5GB; or write p99 >20ms; or Litestream restore >10min |
| 3 — PostgreSQL + replica + pooler | Primary + read replica + pooler | >2,000 concurrent users; or single-node CPU >70% sustained |
The rule, unchanged from ARCHITECTURE.md: do not climb
a rung on speculation — the trigger metric must appear in real
production observability data, and each climb is its own ADR citing that
observation. The fieldbook (Ch10, p.72) names six things explicitly
not on the ladder at all: "a cache server, a queue
service, a feature-flag service, a logging platform, an internal-tools
builder, or a second programming language. Those are not rungs. They are
side doors."
Engineering reference only, synthesized from the Bare Metal Software
fieldbook (Shahid N. Shah, 2026) and this repository's own
docs/decisions/adr-001-core-tech-stack.md and
ARCHITECTURE.md §5.5, which this page quotes directly.
Provenance & review state
- Last reviewed
- Sources
-
- Bare Metal Software (Shahid N. Shah, 2026), Ch. 6, Ch. 10 — Netspective Communications LLC
- Ingested from
-