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 your cloud vendor or managed database disappeared tomorrow, could your system and its regulatory audit trail keep operating? 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.

Sovereign data architecture: SQLite + WAL + Litestream

The pattern is native embedded storage: 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. Queries run in-process, with no network hop between the application and its data. Litestream continuously replicates the WAL to S3-compatible object storage (once per second at its default sync interval), 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. A scheduled, recorded restore drill is the actual proof of sovereignty a vendor's SLA can't substitute for.

The Sovereign Growth Ladder: climb on evidence, never on speculation

Sovereignty doesn't mean refusing to scale — it means scaling on a rule, not a guess. The authoritative Sovereign Growth Ladder (the fieldbook's own Chapter 10, p.71, folded in as supplementary per-feature triggers) has four rungs, each gated by a measured production trigger:

RungTopologyClimb when
0 — Launch (baseline single node)Single VPS; SQLite + WAL; Litestream to object storage; one processStarting rung
1 — Split stores (partitioned stores)Separate SQLite DBs for telemetry vs. CRM/GTM>200 concurrent active users; or SQLITE_BUSY >0.1% of writes
2 — PostgreSQL (self-hosted, single node)CRM/GTM on self-hosted PostgreSQLCRM DB >5GB; or write p99 >20ms; or Litestream restore >10min
3 — PostgreSQL + replica + pooler (distributed replicas)Primary + read replica + pooler>2,000 concurrent users; or single-node CPU >70% sustained

The rule: do not climb a rung on speculation — the trigger metric must appear in real production observability data, and each climb is its own Architecture Decision Record (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."

Regulatory assurance and audit readiness

Owning the platform shortens the evidence chain an auditor has to follow.

  • FDA QMSR (21 CFR Part 820, incorporating ISO 13485:2016): supplier and purchasing controls apply to every outside service your device software depends on. Each managed service you remove is one fewer supplier to qualify, monitor, and document.
  • IEC 62304: every third-party component is SOUP (software of unknown provenance) that must be identified, with its requirements and known anomalies evaluated. An embedded database and an open-source replication tool are two SOUP items you can pin, inspect, and version; a managed platform is SOUP whose version changes on the vendor's schedule.
  • HIPAA Security Rule: the contingency-plan standard (45 CFR §164.308(a)(7)) requires a data backup plan and a disaster recovery plan. A recorded Litestream restore drill is direct evidence for both.
  • FedRAMP: fewer external services means a smaller authorization boundary to describe in the System Security Plan, and fewer interconnections to document and monitor.

Engineering reference only, synthesized from the Bare Metal Software fieldbook (Shahid N. Shah, 2026) and Netspective's own Architecture Decision Records, which this page quotes directly.

Provenance & Review State

Last Reviewed
Authoritative Sources
  • Bare Metal Software (Shahid N. Shah, 2026), Ch. 6, Ch. 10 — Netspective Communications LLC

Sign in or sign up

Enter your email to receive a temporary sign-in link.

By continuing, you agree to our Terms of Service and Privacy Policy.