Your Post-Quantum Migration Has 21 Questions. The Algorithm Answers One.

Picture the shortlist a security architect has in front of them this autumn.

The cloud key service ships ML-KEM key agreement and ML-DSA signing keys. The hardware security module has post-quantum firmware inside a FIPS 140-3 validation. The database negotiates a hybrid post-quantum TLS group and rekeys a tablespace online, without an outage. The backup product calls itself crypto-agile. A cryptography library offers ML-KEM and ML-DSA to any application that wants to build its own envelope.

Every one of those vendors is telling the truth. And the migration is still not planned, because each of them answered the question "which algorithm" and the question the architect has is "what happens to the records over the next thirty years."

The algorithm is one cell in a grid. The grid is what you are buying.

Three tenses

A migration has a beginning, a long middle and a sequel.

Transition is the part everyone plans for: moving records from the old envelope to the new one. It has a start, an end and a completion report.

Maintenance is the part nobody budgets for: months inside a store where some records sit under the old envelope and some under the new, while readers keep reading, keys keep rotating, auditors keep asking, snapshots keep being taken and restored, and people keep leaving with their access revoked behind them.

Evolution is the part that decides whether you did the first one right. NIST deprecates the classical public-key algorithms in 2030 and disallows them in 2035. That is the first scheduled transition, not the last. Parameter sets retire. ML-KEM-1024 will have a successor. Policy changes faster than cryptography. Anyone who has run one migration knows the second is the real test of the first.

A product that helps with transition and is silent on the other two tenses has answered a third of the question.

Seven surfaces

First, the honest statement of what a quantum computer threatens in stored data, because a great deal of money is being spent on the wrong row.

Bulk encryption under AES-256 is not what breaks. Grover's algorithm roughly halves the effective key length, which leaves AES-256 at about 128 bits, and NIST IR 8547 keeps AES approved past 2035. If your database encrypts pages with AES-256 under a symmetric key hierarchy, the bytes on disk have no quantum exposure today, and you should say so to anyone selling you a replacement for them.

What breaks is the asymmetric envelope around those bytes: how a data key is established, wrapped or shared; how stored objects are signed; how the channel between application, store and key service is keyed. And what hurts is not the cryptography at all. It is the operation of changing that envelope on data that already exists.

The surfaces:

1. Transit. TLS and RPC between the application, the store and the key service. A captured session is readable later.
2. Live records. Pages, rows, documents, blobs. Safe under AES-256; exposed through whatever established their keys.
3. Derived data. Indexes, full-text and vector structures, embeddings, materialised views, caches, replicas. Each holds plaintext or its own envelope, and each usually has its own owner.
4. Backups, snapshots and archives. Frozen copies of the envelope as it stood the day they were taken.
5. Key establishment and protection. Where the asymmetric step is, whether a table of keys exists anywhere, and who could take it.
6. Integrity evidence. Signatures over records, batches, manifests, catalogues and audit logs, some of which must still verify in 2040.
7. Authorisation and recovery. Who may read, who may restore, and what a restore is allowed to revive.

The grid

Twenty-one questions. A buyer who can answer all of them has a migration plan. A vendor who can answer their column has a product. An honest "not yet" in a cell is fine. A cell nobody has looked at is the problem.

Print it. Put a product name in every cell it fills. What is left is your project.

Where the shortlist lands

Credit where it is due, because several cells are filled well by products that exist.

The cloud key services fill the transit row to their own endpoints with hybrid post-quantum TLS, and part of the key-establishment row with ML-DSA signing keys and ML-KEM key agreement where offered. Their rotation fills the maintenance cell for the keys they hold. They know nothing about which of your records depend on which key.

The HSM vendors fill the key-establishment and signing cells with post-quantum firmware, wherever you have an HSM. On a vehicle, in an operational-technology enclave, on a forward-deployed kit, there is no HSM to fill them with.

The database's online rekey fills the live-records transition cell for the case it was built for: changing an AES key or mode on a tablespace without taking the database down. It does that by rewriting the datafile. It reports completion at the tablespace, not the record. It carries no algorithm version on the record and it does not serve mixed-version reads by design. It is a real answer to a real question, and it is the incumbent we benchmark against under a protocol published before the first run.¹

The crypto-agile backup products fill the backups row, tied to their own data classification. They cover the copies. The system of record still has to migrate, and the two inventories have to agree.

The cryptography libraries let an application team fill the key-establishment cell one object at a time: a KEM ciphertext per object unless the team builds the amortisation, no query over what was encrypted, and a migration project per data type when the algorithm changes.

Now look at the rows nobody claimed. Derived data is where your search cluster, your vector store and your caches live, each with its own keys and its own owner, and none of them on any vendor's post-quantum roadmap. Authorisation and recovery is where restores go wrong, and no product on the list treats a backup's embedded grants as something current policy overrides.

What lives in the seams

Five products fill perhaps eleven of twenty-one cells. The rest is yours. But the cost is not only the empty cells. It is the seams between the filled ones.

Every place two products meet, something has to exist so they can talk:

• a table of wrapped keys, or an export of one;
• a service credential with standing rights on both sides;
• a synchronisation job, an ETL step or a rekey script that somebody owns and somebody else inherits;
• a manifest signed by one system describing data held by another;
• a reconciliation spreadsheet, because the two inventories disagree.

Each is integration you pay for. Each is a place where the answer to a grid question differs depending on which product you ask. And each is an object an attacker can take: a key table, an export, a credential, a signed manifest that vouches for the wrong thing. Five products give you ten pairwise interfaces. The migration did not just add algorithms to your estate. It added seams, and the seams are exactly the attack surface the algorithms were supposed to shrink.

No datasheet shows this part of the grid, because no single vendor owns it.

The grid when the store fills it

8DB fills the grid from one place because of four decisions made before the first record was written.

The algorithm is a property of the record. Every ciphertext the store produces carries its algorithm version: on live pages, in index entries, in snapshots and replicas. The version is in the record, not in a catalogue beside it, so it goes everywhere the record goes.²

Keys are never stored. Each data key is established by ML-KEM-1024 in a hybrid with X25519 and derived at use from a root secret and the record's governance state at the time it was written. There is no key table, no export of one, and no credential with standing rights to a key service.³

There is one store. Tables, documents, graphs, vectors, time series and spatial data are projections over the same content-addressed atoms. One sealing path, one governance path, one inventory.⁴

Integrity is paid once per batch. One ML-DSA-87 signature over a SHA-384 Merkle root authenticates a batch, and a per-record inclusion proof lets anyone check one record without being handed the database.⁵

Walk the grid with those four in hand.

Transition. "How many records are still under the old envelope" is a query. The re-encryption sweep runs inside the engine: it reads under the retired version, writes under the active one, serves reads the whole time, reports completion per record and lists exceptions. It resumes after a restart. It re-seals the record's index entries and replicas as it goes, because they are the same atoms. There is no datafile rewrite and no tablespace-level report.⁶

Maintenance. A read resolves whichever version the record carries; the application never knows. A retired algorithm is a state on the store: Quarantined refuses new writes and keeps reading until the sweep drains it, then Sealed. The store reports its own cryptographic posture per dataset, algorithm versions with record counts and write-date ranges, key epochs, signature coverage, retirement exposure and migration completion, and exports it as a CycloneDX 1.6 cryptographic bill of materials, snapshots included. The inventory is asked of the data, not of a project plan.⁷

Evolution. The successor to any algorithm is a registered provider. Retiring the old one is a state change. The sweep runs again. Indexes and replicas follow the atoms, so there is no second migration for the search cluster. The version travels into every snapshot, so the backup row and the live-records row are one inventory. Policy is an input to key derivation, so a change in who may read changes what the ciphertext yields, not only the guard in front of it, and a backup taken before a reader was revoked yields that reader nothing when it is restored.⁸

Several of these mechanisms exist in isolation elsewhere. A secrets manager's transit engine versions its ciphertext. A mainstream database keeps legacy decryption alive during an online conversion. Every key service rotates. We did not invent the cells. We removed the seams. One path to seal, one path to govern, one inventory, no key table. The seams that were the attack surface are not defended better. They are absent.

Three buyers, three grids

The shapes below are illustrative. The measurements are in the section that follows.

An agency under M-26-15. Case files since 2011 across a relational system, a document store and a search index; nightly snapshots to object storage kept seven years; a key service adopted in 2019, before which one application wrapped its data keys with RSA in a client-side envelope; a decade of staff whose access was revoked when they left. The grid bites in four places at once. The search index holds plaintext excerpts and is on nobody's migration list. Snapshots from before 2019 carry RSA-wrapped keys and will until they age out, which is after 2035. The client-side envelope is exactly the asymmetric wrap that a harvested copy makes dangerous. And restoring any snapshot revives every reader who was authorised the day it was taken. In 8DB the case files, their indexes and their snapshots are one inventory with one version column, the RSA wrap never existed because keys are derived rather than wrapped, and a restore obeys 2026's authority rather than 2019's.

A bank under the G7 roadmap. Retention of seven to thirty years, which is past 2035 for anything written today. Statements, confirmations and audit logs signed with classical algorithms that an examiner will want verified in a decade. Archive manifests signed by the backup product describing data held by the database. Three changes of key custodian. The integrity row dominates: which signatures must still verify in 2040, whether replacing them costs once per batch or once per record,⁵ and whether a third party can check a single record without being handed the database. One ML-DSA-87 signature per batch with per-record inclusion proofs answers the examiner with a proof, not with access.

A fleet at the edge. Platforms in the field, disconnected for weeks, no key service or HSM reachable, and a threat model that includes capture of the unit. The migration cannot be a data-centre project; it happens on the platform's own hardware while it operates. Keys derived at use mean a captured unit yields ciphertext and no table of keys. One store for telemetry, imagery, relationships and event history means one migration per platform, not one per data type. And the payload carries its own Category 5 protection whether or not the link does.⁹

Ten questions to ask every vendor, including us

1. Is the algorithm a property of each stored record, or of the system? Ours: of the record.²
2. How many records are under the old envelope right now, as a query? Ours: a query, per dataset, exported as a CBOM.⁷
3. Can one read serve two envelope versions without the application knowing? Ours: yes; the version header on the record dispatches the read.⁶
4. What happens to indexes, embeddings, caches and replicas when a record is re-encrypted? Ours: they are the same atoms; the sweep re-seals them.⁶
5. Does a snapshot carry the envelope version with it? Ours: yes, because the version is in the record.²
6. Does a restored backup obey today's policy or the policy of the day it was taken? Ours: today's.⁸
7. Is there a key table anywhere? Ours: no.³
8. Is the post-quantum integrity cost paid per batch or per record, and can a third party verify without the database? Ours: once per batch, with a per-record inclusion proof.⁵
9. Which of the five transitions does each of your tests perform: key rotation, key-protection or KEM change, data-cipher replacement, signature change, or authorisation-policy change? Ours: every test names its operation. A version label over a fixed key proves none of them.¹⁰
10. What have you measured, on what hardware, with what harness? Ours: the section below.

Measurements

Every figure carries its host, date, fixture and build. Release builds throughout.

On four hosts, Windows on a Ryzen 7 7800X3D (2026-07-19), Linux x86_64 on a Xeon (2026-09-11), Windows on a Ryzen 9 9950X3D (2026-09-11, host not quiesced) and Linux aarch64 on a Graviton3 (2026-09-12, host not quiesced), a 115-byte record encrypts to 131 bytes whether its key came from a classical key-derivation function or from ML-KEM, and median per-record encrypt and decrypt times agree within one percent on all four, with 200 operations per arm after warm-up. The post-quantum cost appears once per established key as a 1,616-byte object and once per signed batch as a 4,627-byte ML-DSA-87 signature.

On a fixture of 100,000 records of 115 bytes, batch-signed integrity added 0.054 percent to encrypted storage, 13.1 MB in total, against 579.4 MB for the same records with a signature repeated per row in a conventional database, and 24.5 MB when that database was given application-layer batching. Boundary verification took 0.24 ms on the release path.

ML-KEM-1024 and ML-DSA-87 pass 35 of 35 offline known-answer tests and passed NIST's ACVP demonstration server in June 2026 (session 744723). ML-KEM-1024 decapsulation and ML-DSA-87 verification interoperate with OpenSSL 3.5 in both directions: 15 of 15 checks on x86_64 Windows against OpenSSL 3.5.7 (2026-09-11) and 15 of 15 on aarch64 Linux against OpenSSL 3.5.8 (2026-09-12), with negative controls that flip one bit and watch the verification fail. CAVP algorithm testing through an accredited laboratory is in procurement.

If your records will outlive 2035

Write to hello@8braid.com with the subject line "Grid." Describe your longest-lived dataset: where it lives, what derives from it, how it is backed up, who has been revoked since it was written. We will fill the twenty-one cells with you and run the acceptance test on your data, on your hardware, with the harness in your hands. The reply will be an engineer, not a deck.

Sources and further reading

• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗
• 8DB: We Are Racing Oracle's Online Rekey
• 8DB: Your Backups Are the Quantum Attack Surface Nobody Inventoried
• 8DB: M-26-15's Hardest Instruction Is a Database Operation
• 8DB: The Database That Reports Its Own Cryptography
• 8DB: The Category 5 Bill Is Paid Once or Paid Per Record
• 8DB: Category 5 Keys in Software, on the Hardware You Already Have
• 8DB: An Agent Cannot Leak What It Cannot Decrypt
• 8DB: Six Databases Is Not an Architecture
• 8DB: Post-Quantum Cryptography for Stored Data

Footnotes

1. We Are Racing Oracle's Online Rekey publishes the protocol: wall-clock completion, longest reader stall, throughput during migration, storage written relative to dataset size, per-record completion evidence, interruption and restart, and restored-backup behaviour, on disclosed hardware under a steady live workload. The results table is on the companion evidence page for the sweep. ↩

2. Algorithm-version dispatch: every ciphertext produced through the cryptographic registry carries a 5-byte version header; stored pages carry it ahead of the 2-byte key-epoch tag; legacy pages without either remain readable. Snapshot and replica inventory by version is demonstrated on the same evidence page as the sweep. ↩ ↩² ↩³

3. Key derivation at use: Category 5 Keys in Software, on the Hardware You Already Have. ML-KEM-1024 in a hybrid with X25519 establishes the key; the derivation takes the root secret and the record's governance state at write time. ↩ ↩²

4. 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 shapes from one store. ↩

5. The Category 5 Bill Is Paid Once or Paid Per Record. Fixture: 100,000 records of 115 bytes. Batch-signed integrity added 0.054 percent to encrypted storage, 13.1 MB total, against 579.4 MB for the same records with a 4,627-byte signature repeated per row in a conventional database, and 24.5 MB when that database was given application-layer batching. Boundary verification 0.24 ms on the release path. Host and date are stated in that article with the harness. ↩ ↩² ↩³

6. The running-store transition: write N records under version A, reopen with B active and A registered, read every record with a cold key cache; quarantine A, confirm writes refuse and reads succeed; run the sweep with a reader thread issuing reads throughout, with zero read failures and zero loss; restart mid-sweep and resume to completion; index entries and replicas re-sealed with their records. N of at least 100,000, release profile, x86_64 and aarch64, with sweep throughput in records per second and MB/s, longest read stall and total wall time recorded as typed metrics with their scope. Evidence page: the sweep harness and failure corpus. ↩ ↩² ↩³

7. The Database That Reports Its Own Cryptography. The per-dataset posture report and the CycloneDX 1.6 export are checked into the public evidence folder and validated against the CycloneDX schema in CI. ↩ ↩²

8. Governance as an input to key derivation: An Agent Cannot Leak What It Cannot Decrypt. Recovery under current authority: a backup taken while reader R was authorised, restored into a store that has since revoked R; R receives no protected result, a currently authorised reader succeeds, unknown or stale policy follows the declared quarantine rule, and a policy change during the restore is tested. In CI with its failure corpus. Evidence page: recovery under current authority. ↩ ↩²

9. The channel negotiates a hybrid post-quantum group today (X25519MLKEM768). Payload sealing is Category 5 regardless of the channel. A Category 5 hybrid TLS group is the transport follow-up. ↩

10. The five operations are defined in M-26-15's Hardest Instruction Is a Database Operation. Each test in the sweep harness states which operation it performs and what success means for that operation. ↩

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