Most post-quantum database comparisons hand you one number. Inside it, record encryption, key derivation, key establishment, signatures, indexes and storage layout all moved at the same time, so the number may describe a complete product configuration and still cannot tell you which mechanism you are paying for.
The 8DB benchmark programme separates those questions.
Experiment one: isolate key establishment
The storage, speed and search harness holds the per-record protection path constant. Both classical and post-quantum configurations use AES-256-GCM-SIV for bulk data. The variable is how the dataset page key is established.
For the measured 115-byte record fixture:
| State | Storage per record | Write latency | Read latency |
|---|---|---|---|
| Plaintext | 115 B | n/a | n/a |
| Classical encryption | 131 B | 500 ns | 700 ns |
| Post-quantum encryption | 131 B | 500 ns | 600 ns |
The result is deliberately narrow, and it is the one buyers most need: changing from classical to ML-KEM-1024-based key establishment added zero bytes per record and no measurable per-record latency.1
The post-quantum configuration added one 1,616-byte key envelope for the dataset boundary. At 100,000 records, that envelope was 0.0123 percent of the fixture.
Experiment two: include Category 5 integrity
Confidentiality does not provide non-repudiation or dataset tamper evidence. The full-profile experiment adds ML-DSA-87 signing and the database's integrity boundary.
At 100,000 records of 115 bytes each, the measured storage results were:
| Configuration | Total storage | Relative interpretation |
|---|---|---|
| 8DB full profile | 13.1 MB | Native signed dataset boundary |
| PostgreSQL + independent signatures | 579.4 MB | 4,627-byte signer output repeated per record |
| MongoDB + independent signatures | 495.2 MB | Signature repeated per document path |
8DB's dataset-boundary integrity layer added 0.054 percent over its encrypted state. Verification of the signed boundary measured 0.24 milliseconds. Verifying 100,000 independent signatures took approximately 160 seconds in each conventional-database harness.
The fair counterexample is batching
No competent comparison should imply that a conventional database must always attach an independent signature to every record. If the application's non-repudiation requirements permit batching, a Merkle tree can authenticate many records under one signed root.
The benchmark therefore includes that alternative:
| Configuration | Total storage | Verification |
|---|---|---|
| PostgreSQL + Merkle batch | 24.5 MB | 0.19 s |
| MongoDB + Merkle batch | 19.4 MB | 0.73 s |
Batching dramatically improves the conventional result. It also creates an application-layer authenticated structure that must remain synchronised with mutations, provenance, recovery and authorisation.
The defensible comparison has two conclusions:
- Against independent per-record signing, the native boundary changes storage and verification economics by orders of magnitude.
- Against expert batching, the advantage is integration: the signed structure, inclusion proof, mutation boundary and governed data state belong to the same database architecture.
Search belongs in its own measurement
The search comparison also separates mechanisms. A naively encrypted store cannot safely retain a plaintext side index without changing its leakage model, so the comparator decrypts and scans the authorised records. 8DB opens a sealed index and then searches it.
With 2,000 probes:2
- decrypt and scan measured 1.08 milliseconds;
- sealed-index open and search measured 0.32 milliseconds;
- subsequent operations against an already opened index approach the native lookup path.
The result explains why the location of encryption inside the architecture matters.3
How to read these numbers
Every public chart should keep four distinctions visible:
- measured: produced by the recorded harness and environment;
- derived: calculated directly from measured quantities;
- projected: extrapolated to an application or scale;
- standards-aligned: uses named algorithm families or parameters but is not itself a certification claim.
The key-establishment result is measured. The 0.0123 percent envelope share is derived from the fixture. Any enterprise storage-savings estimate is projected. Alignment with CNSA 2.0 algorithm families is separate from FIPS module validation or an agency authorisation.
The buyer consequence
Post-quantum overhead is not one universal tax. It depends on where the system repeats work.
A database that establishes a protected boundary once and preserves integrity, provenance and inclusion inside that boundary can amortise the public-key cost. A database that receives cryptography as an application-layer attachment may still achieve strong security, but the buyer owns the additional structures and atomicity requirements.
The benchmark question should therefore be: what complete protected state does each configuration deliver, and which part of the system is responsible for keeping it true?
What to bring us
- Your record fixture. Record size, count and the integrity requirement your buyers state. We will run the same harness on it and return the four-way reading above.
- Your batching design. If you already authenticate records under a Merkle root in the application, bring the structure. The integration comparison is the one we want to run against it.
Write to hello@8braid.com with the subject "Category 5 integrity economics: run the harness". You will hear back from an engineer.
Sources and further reading
- NSA CNSA 2.0 Cybersecurity Advisory
- NIST FIPS 203: ML-KEM and FIPS 204: ML-DSA
- 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
- 8DB: Category 5 Keys in Software, on the Hardware You Already Have
Footnotes
-
Measured in the release harness of the storage, speed and search benchmark, on the 115-byte record fixture, with the dataset page key held fixed and only its establishment varied. The governed per-write-key profile, which derives a key per write from the record's governance state, is measured in its own harness and does not inherit this table; its figures are on the stored-data evidence page. ↩
-
Current release harness. ↩
-
This is not a universal encrypted-search result. Dataset size, index shape, process isolation, caching, leakage constraints and access-pattern protection can change the outcome. ↩
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