A database does not become post-quantum because its network connection negotiates a post-quantum key. That protects one journey taken by the data. It says nothing by itself about the state already written to disk, the index used to find it, the backup that can restore it, or the key hierarchy that may need to protect it for decades.
This distinction matters because organizations are beginning to translate a cryptographic migration into procurement language. A buyer sees “PQC supported” and reasonably asks a simpler question: which parts of the data lifecycle are protected, against which attacker, with which algorithms, and what remains outside the boundary?
The database boundary is larger than the wire
Transport security protects data moving between endpoints. A database security boundary must also account for:
- persistent records, pages and large objects;
- indexes, including semantic, vector and full-text structures;
- temporary files, caches and spill paths;
- replication and synchronization between nodes;
- backups, snapshots and crash recovery;
- key establishment, rotation, recovery and revocation;
- signatures, provenance and tamper evidence;
- derived outputs such as previews, embeddings and notifications.
These surfaces do not all require the same mechanism. Symmetric encryption remains the correct primitive for bulk data. Post-quantum public-key algorithms establish or protect the keys and signatures around that data. Search introduces a different question: what is revealed by opening an index, issuing a query or observing an access pattern?
The honest architecture therefore names multiple boundaries instead of using “end to end” as a substitute for a threat model.
Post-quantum does not mean replacing AES
The practical transition is not a post-quantum cipher applied independently to every record. In 8DB’s measured storage path, classical and post-quantum key establishment both lead to the same AES-256-GCM-SIV record protection. The record size remains 131 bytes in both configurations for the 115-byte fixture, and release-mode write and read measurements showed no per-record penalty attributable to the key-establishment choice.
The post-quantum cost is concentrated in a dataset key envelope rather than repeated beside every row. The measured ML-KEM-1024 envelope was 1,616 bytes, which amortized to 0.0123 percent across 100,000 records in that harness.
That is a mechanism-specific result, not permission to say that every use of post-quantum cryptography is free. Signatures are larger. Handshakes have costs. Rotation and recovery still require policy. The architectural advantage is placing each cost at the boundary where it belongs.
Integrity is where naïve designs become expensive
Confidentiality and integrity are separate buyer requirements. If a conventional database attaches an independent ML-DSA-87 signature to every small record, signature storage overwhelms the data. In the executed 100,000-record comparison used by 8Braid, the 8DB full profile occupied 13.1 MB, while independent per-record signing produced 579.4 MB in PostgreSQL and 495.2 MB in MongoDB.
An expert would not necessarily design the alternative that way. A Merkle batch can recover much of the raw efficiency by signing a root rather than every record. That is the correct counterargument—and it changes the real comparison.
The buyer must then ask who maintains the authenticated tree, how mutations remain atomic with the database, how inclusion proofs bind to provenance and policy, and how recovery avoids restoring an inconsistent root. Batching solves a cryptographic cost. Database-native integration solves an operating boundary.
Search is a boundary, not a checkbox
There is no universal form of “search over encrypted data.” The phrase can refer to very different systems:
- decrypting an authorized dataset and scanning it;
- opening an encrypted index inside an authorized process;
- deterministic or order-revealing schemes with explicit leakage;
- trusted hardware that exposes plaintext inside an enclave;
- specialized searchable-encryption protocols;
- private-information-retrieval or homomorphic techniques with different cost profiles.
8DB’s current measured path seals the index under a post-quantum-established dataset key. Opening and searching the sealed index measured 0.32 milliseconds for the 2,000-probe release harness, versus 1.08 milliseconds for the decrypt-and-scan comparator. Once open inside the authorized boundary, repeated lookup can approach the native index path.
The claim is not that queries reveal nothing. The deployment still needs an explicit leakage profile covering index residency, access patterns, result size, caching and process compromise.
What buyers should require
A serious post-quantum database evaluation should require a written answer to each of these questions:
- Which public-key algorithms and parameter sets are used?
- What is protected at rest, in transit and during computation?
- Where does plaintext exist, even temporarily?
- Are indexes protected under the same scope as records?
- How are keys established, rotated, recovered and destroyed?
- What happens to snapshots, replicas and crash-recovery state?
- What integrity or signature model is used?
- What does protected search still reveal?
- Which claims are standards alignment, algorithm validation, module validation or system authorization?
- Can the result be reproduced on the buyer’s workload?
Those questions convert a feature comparison into an inspectable security boundary. That is the level at which a post-quantum database should be evaluated.
The transition is an architecture decision
PQC migration will expose which data systems were designed around a coherent protection boundary and which accumulated security as a set of adjacent products. A transport upgrade is valuable. It is also the beginning of the database problem, not the end.
The durable objective is a data system in which storage, search, integrity, synchronization, recovery and erasure agree about the same protected state. Cryptographic algorithms make that possible. Database architecture determines whether it remains true.
Sources and further reading
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- NSA CNSA 2.0 Cybersecurity Advisory
- 8DB Category 5 data infrastructure
Continue the technical conversation
Bring the workload, boundary and objection.
8Braid can map the article’s claims to an acceptance plan for your security, data and platform teams.
Discuss this work