Post-quantum database comparisons often combine several mechanisms into one number. Record encryption, key derivation, key establishment, signatures, indexes and storage layout move at the same time. The result may describe a complete product configuration, but it does not explain which mechanism caused the cost.
The 8DB benchmark program 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 | — | — |
| Classical encryption | 131 B | 500 ns | 700 ns |
| Post-quantum encryption | 131 B | 500 ns | 600 ns |
The result is deliberately narrow: changing from classical to ML-KEM-1024-based key establishment added zero bytes per record and no measurable per-record latency in this release harness.
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 synchronized with mutations, provenance, recovery and authorization.
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 naïvely encrypted store cannot safely retain a plaintext side index without changing its leakage model, so the comparator decrypts and scans the authorized records. 8DB opens a sealed index and then searches it.
In the current release harness with 2,000 probes:
- 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.
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. The result explains why the location of encryption inside the architecture matters.
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 authorization.
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 amortize 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?
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