A small record in our fixture occupies 115 bytes. An ML-DSA-87 signature occupies 4,627 bytes, about forty times as much. Sign every record separately and the signatures quickly become the largest part of the package.
For teams retaining telemetry, audit events or small evidence records, that is an architectural choice worth making deliberately. One signature per batch can replace thousands of repeated signatures when a shared signing boundary fits the application. Hashes and inclusion proofs connect individual records back to that signed batch.
8DB brings this pattern into its native code: a SHA-384 Merkle tree over record bytes, an ML-DSA-87 signature over its root and record count, and a proof for an individual record. The opportunity is to make strong integrity practical alongside the database's other useful operations.
8DB makes batch proofs a native database capability. The commercial opportunity is the combination: compact integrity proofs alongside useful data structures, access and recovery, with fewer separate pieces for an application team to connect. The PostgreSQL and MongoDB experiments below illustrate why avoiding repeated signatures matters.
<!-- MARKET_VISUAL -->Market context · different routes to verifiable data
Choose the integrity contract, then compare the complete stack.
ML-DSA-87 signed batches with SHA-384 record inclusion proofs.
Per-record and batched ML-DSA-87 demonstrate how signing choices change storage.
Ledger history and blockchain-table verification provide different integrity mechanisms.
The cost worth avoiding is repetition
NIST specifies the 4,627-byte ML-DSA-87 signature in FIPS 204. For 100,000 records, the raw signature arithmetic is straightforward:
| Signing arrangement | Raw signature bytes |
|---|---|
| One signature for each of 100,000 records | 462,700,000 B, or 462.7 MB |
| One signature for one batch | 4,627 B |
These figures count signatures alone. A usable batch also needs its root, count, trusted-key information and whatever tree or proof material the application retains. Its records and encryption have their own footprint. The reduction in repeated signatures is real; total storage savings depend on that complete package.
The signing contract matters just as much. One batch signer attests to the committed group. If each record requires a distinct person's signature or an immediate independently signed receipt, that requirement must be preserved. Batch size is an application decision, including how long a record may wait before the batch is signed.
What the recorded database runs show
In July 2026, we recorded application-layer ML-DSA-87 signing on PostgreSQL 18.4-2 with pgcrypto and MongoDB 8.0.23 with client-side field encryption. Each used 100,000 records of 115 bytes on a Windows machine with a Ryzen 7 7800X3D. We retained both independent-signature and Merkle-batch configurations.
| recorded configuration | Independent signatures | Batched signature |
|---|---|---|
| PostgreSQL, reported relation storage | 579.45 MB | 24.48 MB |
| MongoDB, reported data-collection storage | 495.19 MB | 19.37 MB |
Within each experiment, batching substantially reduced the reported storage. PostgreSQL's batched count includes its separate root/signature table. MongoDB's count covers the data collection and excludes its separate root/signature collection. These are single recorded runs with different storage accounting, so they illustrate the effect within each configuration rather than rank the two products. MB means decimal megabytes.
<!-- STORAGE_VISUAL -->The earlier 8DB fixture produced a 131-byte encrypted buffer from a 115-byte payload. Multiplying that buffer size by 100,000 gives 13.1 MB of record ciphertext. A database's complete disk footprint also includes its structures and metadata. We therefore keep that component calculation separate from the engine-reported storage figures above.
This separation makes the engineering choice clearer: avoid repeating the large signature, then measure everything needed to make the smaller package useful.
July 2026 PostgreSQL experiment · lower storage is better
Same engine. A different signing boundary.
100,000 × 115-byte records · PostgreSQL 18.4-2 + pgcrypto · ML-DSA-87 in application code
Share the signature, preserve the individual check
In the inspected 8DB implementation, each record contributes a leaf hash. The tree combines those hashes into a root. Signing the root together with the record count commits the signer to that batch. A reader can then check one record using its path through the tree and the signed root.
That is useful when an analyst needs one evidence item from a much larger collection, or a receiving device needs to check selected records. The proof path grows logarithmically with batch size. Producing the tree still requires hashing the records, and the retained tree and proof metadata consume space.
<!-- PROOF_VISUAL -->8DB component · conceptual flow, not a timing chart
A small proof connects one record to a signed batch.
- Record bytes
Hash the selected record and follow its inclusion path.
- Committed root + count
Check that the proof reconstructs the batch commitment.
- ML-DSA-87 signature
Verify under the expected trusted key and intended batch context.
Three operations have different purposes:
| Operation | What the verifier establishes |
|---|---|
| Check the root signature | The root and count verify under the selected public key |
| Check a record and its inclusion proof | That record belongs to the authenticated batch |
| Recompute the batch from the records | The presented complete collection matches the committed root |
The caller must establish that the signing key is trusted and that this is the intended batch and revision. A valid signature by an arbitrary key cannot supply that context.
The current membership method checks the root signature on each call. One stored signature therefore does not mean one verification operation for every possible access pattern. This implementation detail belongs in performance accounting when an application checks many records.
The source includes tests for altered records, forged roots, wrong keys and mismatched record counts. These establish the intended component checks; a deployment still needs its own integration and recovery qualification. A timing for checking only a signed root cannot stand in for a complete data audit.
Where 8DB fits among the alternatives
An application built on PostgreSQL or MongoDB can implement signed batches, as our experiments demonstrate. Established database products also offer native integrity mechanisms: SQL Server Ledger retains verifiable history using hash structures and external digests; Oracle blockchain tables expose row and signature verification operations. 8DB’s proposition is native post-quantum batch proofs alongside its broader data model.
8DB's case is the combination: post-quantum batch authentication in a native component, within an omnimodal database that also provides relationship, time-series and other data representations. A buyer can evaluate how well these capabilities work together and how much separate integration they replace. Our source review establishes the batch mechanism; a matched deployment comparison must establish any advantage in total cost or operational simplicity.
For the broader product picture, our separately measured time-series ingestion and cross-modal querying articles cover other paths. Those results retain their own workloads and guarantees; they do not time this integrity component operating alongside them.
Put the complete protected package on the scales
The best first comparison starts with your actual records and signing requirement. Measure record storage, retained hashes, proofs, signatures and key metadata together. Then check the operations your application will perform: signing a batch, verifying one record, auditing the whole batch, updating data and recovering after an interruption.
Keep encryption, durability and authorization requirements consistent across the compared deployments. ML-DSA-87 is a standardized algorithm; using it alone does not establish a validated cryptographic module or an approved deployment.
Bring us one representative record format and the statement a signature must prove. We can identify the right signing boundary and scope an evaluation against your current stack. The goal is useful, verifiable data with less repeated cryptographic work.
Discuss your integrity workload.
Evidence scope Source-inspected native component · Recorded storage experiments · Distinct verification contracts. Explore the evidence. Methods and retained scope notes.
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