Your Migration Plan Encrypts One Copy of Each Record. Your Stack Holds Eleven.

Take one record. Call it 4471. It is a customer's account row: a name, an address, a balance, a note from a support call.

Now count where it lives.

1. The primary table, encrypted at rest. This is the copy the migration plan is about.
2. The write-ahead log that made the write durable.
3. The read replica, with its own key hierarchy and its own backup schedule.
4. Last night's snapshot in object storage, retained for seven years.
5. The full-text index, where the support note is tokenised, position by position.
6. The vector store, where the note became an embedding so an agent can find "customers who complained about the same thing."
7. The application cache, where the whole row sits in memory and on local SSD because it was read twice in a minute.
8. The reporting table that materialises balances by region, with 4471's balance summed inside it.
9. The warehouse, where the ETL job landed a copy at 02:00 for the analytics team.
10. The CSV that went to the collections partner in March.
11. The log line that recorded the API call, with the account number in the URL.

Eleven. The migration plan encrypts one of them. It is not even the interesting one.

The test for a copy

Here is the only test you need. If a system can answer a question about the record, it is holding a copy of the record.

The full-text index answers "which records mention this." The vector store answers "which records are like this one." The cache answers "what is this record." The reporting table answers "what did this record contribute." The replica answers everything the primary does. The log answers "who touched it and when."

Under that test, derived data is data. Not metadata, not an optimisation, not a cache that can be flushed and forgotten. It is the record, wearing a different structure, protected by a different envelope, owned by a different team.

Why the other ten are the exposed half

The primary is the copy with the most attention. It has a DBA, an encryption-at-rest checkbox, a key service and an audit. The other ten have less of everything.

The full-text index stores the tokens of the support note, usually in the clear, often with the positions that let you reassemble the sentence. The vector store holds an embedding, and published inversion attacks recover most of a short text from its embedding.¹ The cache holds plaintext in memory and, on many platforms, on the local disk. The replica has its own keys, wrapped by its own service, and its snapshots are taken by a different tool. The warehouse decrypts on load, because analysts cannot query ciphertext. The partner export left the building. The log was never in scope for encryption at all.

And every one of those copies carries the envelope problem separately. Each has a key, wrapped by something, signed by something, retained under its own schedule. When the algorithm behind one of those envelopes retires, each copy is its own migration, and each is on the roadmap of a different vendor, or of no vendor.

Nobody owns the census

Draw the org chart over the eleven copies.

The database team owns 1, 2 and 3. Platform owns 4 and 7. The search team owns 5. The machine-learning platform owns 6. The data team owns 8 and 9. Finance sent 10. Observability owns 11 and does not think of it as data.

Five teams, one record, no owner for the whole. The plan that says "re-encrypt the database" has assigned one of eleven copies to one of five teams and declared the migration scoped. When an auditor asks where record 4471 depends on an algorithm that retires in 2030, the honest answer is a meeting.

The seam tax

Each of the other ten copies is manufactured by a pipeline: a change-data-capture stream, an indexer, an embedding job, a cache fill, an ETL run, an export script. Every pipeline decrypts on one side and re-encrypts on the other, or does not. Every pipeline re-decides governance, because whoever wrote it decided which fields to carry and who could read the destination.

Pipelines are the seams between systems, and seams are where three things live: integration you pay for, answers that disagree depending on which system you ask, and objects an attacker can take. A credential with standing rights to the primary and the search cluster. A wrapped key in the indexer's configuration. A staging bucket for the ETL. Ten copies, ten pipelines, ten seams. The migration did not just add algorithms to the estate. It added seams, and the seams are exactly the attack surface the algorithms were meant to shrink.

One record, one body

8DB removes the copies rather than defending them.

The record is one content-addressed atom, sealed at write under a key established by ML-KEM-1024 in a hybrid with X25519 and derived at use from a root secret and the record's governance state. The table view, the document view, the graph edges, the vector for nearest-neighbour search, the time series and the spatial position are projections over that atom, not second copies with second envelopes.² The index entry that lets you find 4471 by a word in the support note carries the same algorithm version and the same governance as 4471 itself, and a reader who cannot derive the record's key cannot derive the entry's.³ The embedding that lets an agent find records like 4471 is an atom sealed the same way. There is no cache tier deciding on its own what to hold in the clear; the projection is served from the sealed store.

So the census collapses. The write-ahead log, the replica and the snapshot carry the record's version because the version is in the record. The index and the embedding are re-sealed when the record is, because they are the same atom. When a record leaves the store, it leaves as the sealed object it is, with its version and its inclusion proof, so the partner receives a record that still knows what protects it.⁴ A fact is written once, sealed once, governed once and attributed once.

We have run this at a size that matters. The full public OpenSanctions corpus, about 4.28 million records across 29 entity types, went in once and answered graph questions, time-window questions and text questions from the same atoms, with every finding carrying its source records and hashes.⁵ Thirteen million map entities of a city render on a phone directly from the sealed binary substrate, with no second, decoded copy of the map.⁶ One store is not a slogan about simplicity. It is the reason there is one migration.

Run the census this week

Take your most sensitive table. List every system that can answer a question about one of its rows. Count. Then, for each copy, write down three things: the algorithm that established or wrapped its key, the team that owns it, and the tool that would migrate it. Where any of the three is blank, you have found a seam.

Write to hello@8braid.com with the subject line "Census" and send the list. We will count the copies with you, fill the migration grid for each, and show you what the list looks like when the copies are projections of one sealed record. The reply will be an engineer, not a deck.

Sources and further reading

• Morris, Kuleshov, Shmatikov and Rush: Text Embeddings Reveal (Almost) As Much As Text ↗
• 8DB: Your Post-Quantum Migration Has 21 Questions. The Algorithm Answers One.
• 8DB: Six Databases Is Not an Architecture
• 8DB: Data Modality Is a Projection, Not a Product Boundary
• 8DB: The Sanctions Network Has a Shape, and the Lists Do Not Show It
• 8DB: Entity Resolution That Shows Its Work
• 8DB: A City of Thirteen Million Entities on a Phone
• 8DB: What an Independent Evaluator Should Be Able to Run

Footnotes

1. Morris, Kuleshov, Shmatikov and Rush, "Text Embeddings Reveal (Almost) As Much As Text" (Vec2Text, 2023) recovers 92 percent of 32-token inputs exactly from their embeddings. Later work extends the result to longer inputs and other embedding models. ↩

2. Six Databases Is Not an Architecture and Data Modality Is a Projection describe the atom store and its projections, with the evaluation package that checks byte-correct results across the projections from one store and one sealing path. ↩

3. The sealed lexical and vector index path, with its leakage profile (equality, access, frequency and volume patterns) documented and bounded by tests. Evidence page: the sealed-index leakage profile. ↩

4. The authenticated sealed-transfer primitive is the third of the four claims in What an Independent Evaluator Should Be Able to Run: ML-KEM-1024 and ML-DSA-87, tamper and replay rejected. ↩

5. The Sanctions Network Has a Shape, and the Lists Do Not Show It and Entity Resolution That Shows Its Work: about 4.28 million records, 29 entity types, byte-deterministic across machines. ↩

6. A City of Thirteen Million Entities on a Phone: OpenStreetMap rendered on device from the binary substrate without a decoded intermediate copy, with the limits reached at planetary scale stated there. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work