Your Database Doesn't Know It Defected

Pillar 03 · Residency

Your tools already speak S4 — S3 above the line, Canadian custody below it.

S4 is exactly what it sounds like. S3 plus Sovereign. The name is also literal — SigV4, the AWS signature scheme every S3 client already implements.

When we built SkyeBucket — the S4 object interface on the SkyeConnex Raidr.cloud custody engine — we made one boring decision early. Speak Amazon's S3 API. Signature for signature. Don't invent a better one.

Boring decisions compound.

The S3 API is the universal socket of data infrastructure. Twenty years after Amazon published it, every database, backup platform, analytics engine, log pipeline and media workflow assumes an S3 endpoint exists somewhere. None of them care whose endpoint. They care that signatures verify, ranged reads return the right bytes, and multipart uploads assemble.

Which means all of them can write into Canadian threshold custody without knowing it. Zero code changes.

Above the endpoint: standard S3. Below it: every object encrypted, split 5+2 with erasure coding, fragments distributed across independent Canadian jurisdictions. No site holds enough to reconstruct anything. Keys exist only under the owner's zero-knowledge hierarchy. Every custody event lands in an append-only ledger with post-quantum signatures. The application sees a bucket. The sovereignty happens underneath.

What that unlocks, market by market.

Databases

We validated this with MariaDB. Its S3 storage engine converts a table to object storage with one statement: . In our test, a stock MariaDB server and a stock desktop SQL client ran indexed point lookups against a table whose disk was SkyeBucket. The engine issued ranged reads for specific blocks. Page checksums verified every fetch. Underneath, each object existed only as encrypted fragments across multiple connexions.

Nobody told the database. Nothing needed to.

Every organization has this data. Closed case files. Historical transactions. Last fiscal year. Must be retained, rarely touched, and today it sits either on expensive primary storage or in a foreign hyperscaler's archive tier — where the CLOUD Act reaches it regardless of region. Moving it to sovereign custody is one statement for MariaDB. One repository URL for a Postgres backup estate. One endpoint change for ClickHouse's automatic hot/cold tiering.

Not a migration. A config change that relocates legal control.

Microsoft 365

The one estate every Canadian department runs. By default, none of its data paths lead anywhere sovereign.

Two of them are S3-shaped. Tenant backup — Exchange, SharePoint, OneDrive, Teams — is a compliance checkbox in every department and MSP contract, and the dominant backup platforms already support S3-compatible repositories, including self-hosted ones. Your tenant's backups in Canadian threshold custody, using software your IT team already licenses. New endpoint, same tooling.

Audit telemetry is the second path. Management Activity API and Event Hub streams, a standard log shipper, an S3 destination. Which raises a bigger point.

Security and audit

Your log of record sits in infrastructure operated by someone who could alter or withhold it. Whose jurisdiction may compel exactly that. Most SIEM architectures politely ignore this.

The modern pattern — decouple log storage from the SIEM, land raw events in object storage, query in place — maps straight onto sovereign custody. Events become objects. Objects become jurisdictionally fragmented shares. The custody ledger gives you an independent, cryptographically verifiable record that nothing was touched since ingestion.

If your logs may one day face a court, a privacy commissioner or an incident inquiry, "tamper-evident by architecture, held under Canadian law" is a different class of claim than "stored in our SIEM vendor's cloud."

Analytics

The centre of gravity moved to open formats on object storage. Parquet. Iceberg. DuckDB on a laptop, Spark or Trino in a cluster, ClickHouse for speed. The engines come to the data now.

Point that at a sovereign endpoint and you get what government data-sharing initiatives have chased for a decade: multiple departments and engines analyzing shared datasets that never leave custody. Access mediated by keys, not copies. Health research on de-identified datasets in place. Statistical agencies granting time-boxed analytical access without shipping extracts.

Compute is interchangeable. Custody is constant.

AI

The AI supply chain runs on object storage at both ends. Corpora and embeddings in. Checkpoints and weights out. Every serious vector database and training pipeline persists to S3.

Here the custody question gets sharp. A fine-tuned model is a derivative of everything it saw. The checkpoint file is the most concentrated sensitive artifact your organization produces. Land that lifecycle in sovereign custody — the substrate SkyeGXU's attested runtime already consumes — and "where are the weights, who can reach them" has a jurisdictional answer instead of a contractual one.

Large files

Broadcast. Film. Geospatial. Simulation. Genomics. Terabyte-scale working assets, and every transfer tool and MAM system in those industries terminates in a bucket. Canadian productions with residency obligations. Court media evidence. Licensed satellite imagery. The workflow stays. The bucket changes nationality.

MSPs

Everything above is sellable without engineering. MSP platforms are built around S3 targets, so a sovereign tier is a pricing-sheet addition, not a practice build. Your hyperscaler-reselling competitors can't match it structurally. Not won't. Can't.

The pattern

Read the list again. No application changed. No workflow changed. Every first workload is small — a cold tier, a backup repo, a log destination. One team, one budget cycle, expandable from there.

Sovereignty adoption fails when it demands replatforming. It succeeds when it's a configuration change.

One caution before you believe any vendor saying "S3-compatible," including us. The easy parts of the API are easy. The hard parts — strict SigV4 semantics, parallel multipart under load, the ranged reads databases live on, the conditional writes Iceberg commits depend on — are where checkbox-compatible stores fall over. These claims should be test results, not adjectives. Named engines, named versions, named operations.

So here are ours. MariaDB 11.4 through libmarias3. DuckDB 1.5.5 through httpfs. ClickHouse 24.8 through the AWS C++ SDK. Three independent client implementations. Writes, reads, indexed point lookups, predicate pushdown. All passing.

The ladder also did its real job: it found a bug. MariaDB writes internal keys prefixed with during table operations, and our gateway mishandled the URL-encoding through signature verification. Found by running a real client, fixed for every client, documented. That's the difference between a compatibility claim and a conformance discipline — one of them surfaces its own defects in the open.

And one behavior we won't apologize for: sign a request against the wrong region and the gateway rejects it. Some stores accept anything. We validate what AWS validates. Strict is the feature.

Your tools already speak S3. S4 is the same conversation under Canadian law. The defection is one endpoint away.