Four Illusions of Post-Quantum Database Security

Post-quantum security belongs in the database.

Your data needs protection while an application stores it, shares it, works offline and changes the cryptography years later. Application teams should be able to inherit that protection architecture from the database they build on.

We built 8DB around that whole job. It brings protected local storage, authenticated post-quantum exchange and a managed cryptographic lifecycle into an embeddable, omnimodal database. The engine runs inside the application and supports multiple ways to work with information, including documents, graphs, vectors, time series and spatial data.¹³⁴⁶

8DB treats protection as a database primitive. The engine handles it as part of storing, admitting and maintaining data. Its node messages carry their own protection, independent of TLS. Bringing those responsibilities together changes how much security integration an application team has to own.¹⁶

Four illusions obscure that opportunity:

These are the questions to follow through the rest of the article: who can read the record, what work protects it, who assembles that protection, and what happens when it must change.

Illusion 1: A quantum-safe connection protects the whole data journey

8DB protects a message for its intended recipient before handing it to the network. A relay can carry the encrypted frame without holding the keys to its contents. The receiving node verifies and opens the message, then protects the local records under its own storage keys.¹

Follow one record through the documented node workflow. It begins in a protected local store. An authorized operation prepares it for exchange. The sender encrypts a new message for the receiving node and authenticates the frame. The recipient checks the sender, message context and current authority before applying the record and sealing its local copy.

The nodes can retain separate storage roots. The sender's at-rest key stays with the sender. The recipient gets the information it is authorized to receive, protected in transit and then under its own local storage protection.¹

That is a concrete distinction from protecting a connection. TLS protects traffic between the endpoints of that connection. When a gateway terminates TLS, it can see plaintext unless the application supplies an additional layer of content protection. 8DB's recipient protection travels inside that outer connection, so the forwarding infrastructure can do its job without gaining access to the payload.¹⁹

The reviewed exchange uses ML-KEM-1024 to establish the message secret, ML-DSA-87 to authenticate the frame and AES-256 to encrypt the payload. Its message protection is independent of TLS. Trusted enrollment, endpoint key custody and secure implementations remain the basis of that protection; network addresses, timing and message lengths can remain visible.¹

For an evaluation, start with the records your application needs to exchange and the parties allowed to read them. That gives the team a concrete path from the demonstrated protection architecture to your workload.¹³

For teams using infrastructure they do not control, the practical payoff is clear: choose who may read the information independently of who carries its bytes. That choice matters now, because an attacker can retain a vulnerable encrypted exchange today and attempt to decrypt it later.²

Illusion 2: Every record must carry the full PQC cost

8DB separates the expensive public-key work from the symmetric encryption of stored records. Key establishment, record encryption and shared integrity boundaries have distinct jobs. The selected protection profile determines where their cryptographic objects belong.⁵

This matters for small records. A signature or key-establishment object can be much larger than a sensor reading or a short database entry. The architecture determines how often that object has to be stored or processed.

In the controlled same-cipher comparison, a 115-byte input produced a 131-byte ciphertext with either classical or post-quantum-established keys. The additional PQC ciphertext cost was zero bytes per record. Across the four published host pairs, median encryption times differed by no more than 0.55%.⁵

These measurements time the same AES-256-GCM-SIV operation with keys already established. They show that changing the key-establishment path can preserve the compact record representation and closely matched encryption medians. Envelopes, signatures, database structures and complete network operations have separate costs.

8DB supplies an integrated implementation of that storage approach. The engineering choice preserves a compact symmetric record path while assigning public-key and integrity work to their actual boundaries. Shared signatures can amortize authentication work across records; the chosen boundary determines what a recipient must obtain and verify.⁵

A complete exchange has a different cost boundary. The documented node-message path performs fresh encapsulation and signing for each frame. Other systems can also amortize cryptographic work, including TLS handshakes across a reused connection. Compare the total work required to deliver an authorized, durable record, alongside the cost of storing it. The published record test establishes the scoped storage result above.¹⁵⁹

Illusion 3: Secure components automatically produce a secure system

8DB puts protected data and useful work in the same embeddable engine. That gives application teams a common architecture for local storage, authority and authenticated exchange.¹³

Consider what a team otherwise has to decide. Who may open a local record? Which identity is allowed to send it? What happens when the network disappears? Which permissions apply when an old backup is restored? Individually secure components still need a coherent answer across those handoffs.

Those answers are part of the product. They belong in its design, its tests and its operating procedures.

Put the engine where the application runs

8DB runs inside the application. Its published platform coverage includes iOS, watchOS, macOS, Android, Windows and Linux. That creates a common foundation for local data work across phones, watches, desktops and servers, with the workload sized to the device.¹⁵

Its tested core storage operations work with the network disabled, without requiring an online external key-management or identity service. Provisioned secret root material and governance context support local key derivation. A disconnected application can continue its supported protected local work while exchange waits for connectivity.³

For a field team, the useful consequence is access to the information already available on its devices. For the application developer, it is a local protection mechanism that can be exercised and inspected inside the application.

Give the same information more uses

A maintenance record can answer several questions. A technician wants its service history. An engineer wants related sensor trends. A planner wants its location. An AI application wants similar incidents.

8DB's omnimodal architecture represents, indexes and queries shared typed information through different data models. Documents, graphs and hypergraphs, dense and sparse vectors, time series and spatial structures are native parts of that architecture. Media representations have their own supported formats and operations.⁴¹⁶

Each additional use can draw on the same governed information foundation. When that replaces a separately maintained database or exported copy, the team also removes a place where access rules, encryption, retention and migration would have to be coordinated.

Start with the data shapes, devices and operations your application needs. That makes an evaluation concrete: which handoffs and copies can a shared engine remove, and what useful work can it keep together?¹³⁷¹⁶

That is the deployment question worth asking: how much of your application's useful work can share one protection lifecycle?

Illusion 4: Post-quantum migration is a one-time upgrade

8DB treats cryptographic change as part of managing stored data. The engine has to know how to read existing protection, apply a new profile, recover interrupted work and account for the managed copies that remain.⁶¹⁸

This is where a simple phrase like "re-encrypt with new keys" loses most of the operational story. A live store can move forward while a backup retains the old profile. An authorized reader can be revoked before that backup is restored. A migration can be interrupted halfway through its work.

Return to the record we followed earlier. Its payload still matters, but the protection selected when it was written may need to change. So may the authority to read it. The database needs an explicit way to handle both.

8DB's versioned ciphertext lets its registry select the implementation needed to read a record. Supported old and new versions can coexist while new writes use the selected version. Configured controls can stop new use of an old algorithm while permitting controlled migration.⁶

8DB prepares and verifies a replacement generation before activation. Current-authority checks govern migration and managed recovery. Managed-copy accounting and dataset reports make the remaining obligations inspectable: which registered copies match the target, which differ, and which still need an observation.⁶¹⁸

A 100,000-record store migrated and recovered its exact contents, including interruption and resume. The demonstrated transition changed key derivation from HKDF-SHA-256 to HKDF-SHA-384 while retaining AES-256-GCM-SIV. That gives customers a concrete lifecycle to evaluate against their own algorithm and availability requirements.¹⁹

The practical advance is an inspectable process for protection changes. An operator can connect the transformation to recovered content, current authority and the managed copies still in scope. Migration consumes processing and storage; the integration benefit comes from handling these responsibilities through the engine's lifecycle.

NIST treats cryptographic agility as an ongoing capability, including stored-data encryption and existing signatures. Those are distinct obligations. Re-encrypting a payload changes its confidentiality protection; preserving the meaning of an older signature requires attention to its own evidence and lifecycle.¹⁷

For long-lived information, the next cryptographic transition belongs in today's database decision.

Compare the application you would actually have to operate

The market offers several useful starting points. The decision is which architecture delivers your required workflow and how much additional work your team must own.

Oracle and SQLCipher also have migration tools. The comparison includes their scope and the orchestration around them. For example, Oracle supports online tablespace rekeying and interrupted-conversion completion; SQLCipher provides rekeying and migration APIs, with application responsibilities for detection, invocation and some legacy conversions.²⁰²¹

A useful evaluation follows the same record through storage, exchange, useful operations, protection changes and recovery. Count the services, custom code, copies and operating procedures needed to complete that job. That is where an integrated engine can change the application team's workload.

What to demand from a post-quantum database

The four illusions point to one architectural choice: make protection part of how the database stores, shares, uses and maintains information.

That is the choice we made with 8DB. We have built the local protection, recipient exchange and lifecycle mechanisms described here into an embeddable engine. Its omnimodal design extends the value of that foundation as more useful operations share the same information.

Our conviction is simple: every new use of your data should inherit its protection.

Bring us one data journey: where a record starts, who needs it, who must never be able to read it, and what has to survive an interruption or cryptographic change. We can walk through the relevant 8DB implementation and evidence, identify the supported starting point, and make the remaining integration work explicit.

Explore your data journey with 8Braid.

For a closer look, read about protected local work while disconnected, repeatable migration, and identifying managed copies that still need attention.

Sources and technical notes

1. Protected-node implementation and trust boundaries. Describes the reviewed RequiredMeshNode composition, lexical admission allowlist, trusted identities, recipient-specific message encryption and local resealing. Intermediary confidentiality assumes secure endpoint keys and implementations; it does not provide traffic-analysis or availability protection.

2. NIST: What is post-quantum cryptography?. Explains the public-key threat and harvest-now-decrypt-later rationale. The article makes no prediction of a quantum-computer arrival date.

3. 8DB disconnected-store evidence scope. Reports defined local storage shapes, governance and recovery tests without mandatory online key or identity services. Its separate sealed-transfer primitive must not be conflated with the newer integrated node composition. Customer hardware, deployment and schema acceptance remain separate work.

4. 8DB modality architecture. Describes projections over shared typed information. Reduced copies and operating effort are architectural opportunities whose extent depends on the application.

5. Record measurements and full cost accounting; newer paired-component methodology. The four-host figures use a 115-byte input, 200 timed operations per arm after warm-up, and the same AES-256-GCM-SIV cipher, with setup outside the timer. Encryption medians, classical/PQC in nanoseconds: Ryzen 7 Windows 500/500; Xeon Linux 733/737; Ryzen 9 Windows 500/500; Graviton3 Linux 1,176/1,175. The 0.55% bound describes these medians; it is not a statistical equivalence claim or a decryption, governed-write, battery or full-database result. These are vendor-run measurements. The message path separately performs fresh encapsulation and signing per frame.

6. Stored-data lifecycle and migration evidence and managed cryptographic inventory. Describe current-authority checks, managed-copy accounting, recovery and CycloneDX 1.6 posture export. Inventory evidence supports assessment. Product certification and coverage of unmanaged historical copies require separate evidence.

7. Current qualification register. Identifies tested sources, retained results and remaining package and sustained-operation gates. Separate successful component tests do not establish qualification of every combined workload.

8. Oracle encryption and keystore options, Oracle PQ connection documentation, and MongoDB client-side field encryption. These illustrate real alternative capabilities, rather than a uniform competitor architecture.

9. TLS 1.3 protocol. Handshake establishment, resumed connections and subsequent application traffic have different costs. A handshake must not be charged to every database record when the application reuses a connection.

10. IBM Db2 quantum-safe announcement; Db2 native encryption and local or centralized keystores. Server-side encrypted storage and PQ connection support are genuine capabilities. Their trust boundary depends on configuration and topology.

11. SQLCipher design. Documents encrypted SQLite storage, page encryption and integrity protection. A complete sharing design requires additional components; the article does not claim that such a design cannot use PQ protection.

12. Couchbase Lite peer synchronization. Documents direct peer replication, TLS options, conflict management and network resiliency. These capabilities are not evidence of equivalence to the specific 8DB PQ message profile; neither does this comparison establish that every Couchbase configuration lacks PQ support.

13. SurrealDB capabilities; embedded deployment. Establishes overlap in embedded multimodel positioning. Protection, operator coverage and deployment qualification require a separate comparison.

14. PostgreSQL 18 TLS configuration; OpenSSL 3.5 configuration. The composed hybrid-PQ option is an inference from configurable PostgreSQL groups and OpenSSL support. It requires compatible builds, clients and successful negotiation; it is not the default PostgreSQL 18 group list or evidence of PQ certificate authentication.

15. 8DB technology and platform coverage. Lists iOS, watchOS, macOS, Windows, Linux and Android. Published platform coverage is distinct from qualification of each workload, operator, protection profile and mixed-device exchange. No universal battery or resource-efficiency result is claimed.

16. 8DB native modalities and operator scope. Describes the supported representations and their individual limits. Storing media does not supply every codec, embedding model or interpretation pipeline; advanced projections and persistence paths have specific qualifications.

17. NIST CSWP 39, Considerations for Achieving Crypto Agility, updated June 2026. Discusses continuing cryptographic transitions, policy and implementation concerns; section 5.1 explicitly addresses stored-data encryption and existing signatures.

18. 8DB cryptographic inventory and posture reporting. Describes dataset-level information on cryptographic versions, key epochs, signatures and migration, including managed-copy evidence. Reporting supports an assessment; it does not itself establish certification or discover every unmanaged copy.

19. Live HKDF migration evidence, September 15–16, 2026. Vendor-run synthetic lexical workload; HKDF-SHA-256 to HKDF-SHA-384 with the record cipher unchanged. Retained runs include interrupted and resumed migration and exact 100,000-record recovery. Some runs failed read-deadline gates; the cause of earlier misses is unresolved, and process outages are recorded separately. This is not a zero-downtime claim, an ML-KEM-successor migration result, or proof that arbitrary future algorithms need no implementation work. The separate p38 live-algorithm-swap placeholder reports that nothing ran and is not used as proof here.

20. Oracle online tablespace encryption conversions and rekeying. Documents online rekeying with a different supported algorithm, additional-space requirements and interrupted-conversion completion. Compare its tablespace scope with the specific 8DB record-version and managed-lifecycle path; agility is not exclusive to 8DB.

21. SQLCipher API: rekey, cipher_migrate, compatibility and export. Documents existing encrypted-database migration tools. Key changes, format/settings migration and replacement of an underlying cryptographic algorithm are different operations and should be compared explicitly.

Evidence scope Architecture, primary sources and scoped measurements. Explore the evidence. The reviewed integrated profile uses a defined structured-record schema; integrating and qualifying your schema is the first step of an evaluation. Methods and retained scope notes.

Published and discussed

GitHub ↗