Four Illusions of Post-Quantum Database Security

Your database connection can be quantum-safe while an intermediary can still read the data. Your record encryption can be fast while the complete transfer has additional costs. Your components can each be secure while their integration leaves a gap.

Your data may also outlive the cryptography chosen to protect it. A database decision commits your team to years of storage, exchange, useful work and change. Its security needs to hold through that whole life.

Oracle and IBM Db2 offer post-quantum connection options and encrypted storage. MongoDB offers client-side field encryption. Embedded databases bring useful capabilities to devices. The distinctions between these approaches matter because they determine who holds the keys, which infrastructure must be trusted and what the application team must assemble.⁸¹⁰¹¹

Four assumptions can obscure those distinctions. Examining them reveals where a database architecture can make a practical difference.

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

A connection has endpoints. Information has a longer life. Protecting one link leaves the rest of that life to the surrounding system: local stores, forwarding services, recipient permissions and recovery paths.⁹

A record created today may remain sensitive for decades. An attacker can retain an encrypted exchange now and attempt to break vulnerable public-key protection later. A future upgrade cannot recall a copy already captured.²

8DB lets participating nodes establish protection before handing a message to the network. Its reviewed exchange uses ML-KEM-1024 to establish the message secret and ML-DSA-87 to authenticate the frame, with AES-256 protecting the payload. A relay can forward the encrypted frame without holding its payload keys. The authorized recipient verifies and opens the message, then protects the local records under its own storage keys.¹

You decide which endpoints receive that authority. A forwarding service needs permission to carry bytes; it does not need permission to read the information inside them.

For a team building through infrastructure it does not operate, that distinction is valuable. Payload confidentiality can remain with the application’s authorized endpoints even when an intermediary terminates an outer connection. Endpoint security, trusted enrollment and key custody still matter; routing metadata can remain visible.

The practical comparison with Oracle or Db2 connection encryption is who can open the content along the route. A database connection protects traffic between its TLS endpoints. In a topology where a gateway terminates TLS, keeping content secret from that gateway requires protection inside the connection. 8DB’s reviewed message path supplies that recipient protection as part of the node’s database exchange.¹⁸¹⁰

PostgreSQL 18 can expose TLS key-exchange groups supplied by its OpenSSL build; a compatible OpenSSL 3.5 configuration and clients can provide hybrid PQ key establishment. That gives an application another credible connection-security option. Endpoint storage, opaque relay payloads, application schemas and the recovery policy still have to fit the intended workflow.¹⁴

MongoDB’s client-side field encryption also keeps protected content unreadable to the database server. That is a credible alternative when selected fields and a server database fit the application. 8DB combines its supported recipient exchange with local admission and resealing inside an embedded node. Compare those complete workflows, including keys, local storage and recovery, when deciding how much application integration each requires.¹⁸

The documented integrated node profile currently admits canonical WordNet lexical records. Other application schemas require integration and qualification. That identifies the starting point for a concrete evaluation of your data path.¹

Illusion 2: Every record must carry the full PQC cost

The placement of cryptographic work determines how often you pay for it. A design that repeats large public-key objects for every small record has a different cost structure from one that shares them across a dataset.

8DB’s measured storage design separates key establishment, symmetric record encryption and shared integrity boundaries. AES handles the record content. The selected profile determines where key-establishment objects, signatures and proofs belong.⁵

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.

For applications managing many small records, preserving that representation matters. Repeating a large signature for every record can overwhelm a small payload; signing a shared integrity boundary can amortize that cost. The chosen boundary also changes what a recipient must obtain and verify, so the comparison must preserve the required authentication semantics.

A PostgreSQL or MongoDB application can also use symmetric record encryption, batch signatures and amortize key establishment. Those techniques are available to an alternative design. 8DB supplies an integrated implementation of the measured approach; its record result demonstrates that PQ key establishment can preserve storage density and the fast AES path. The published paired test does not establish that an equivalently configured competitor must be slower or larger.⁵

TLS handshakes can serve many writes over one connection. Adding a handshake charge to every competitor record would exaggerate their cost. Equally, an 8DB record-encryption microbenchmark cannot stand in for a complete protected transfer. A useful evaluation measures cold connections and steady operation separately, then counts all the bytes and work needed to deliver an authorized, durable record.¹⁵⁹

Illusion 3: Secure components automatically produce a secure system

An encrypted local store, a protected connection and a key-management service each solve a useful problem. The application still needs them to agree on who can open a record, what happens offline, how policy changes propagate and what a restored copy is allowed to reveal.

Those decisions become the product team’s responsibility wherever the selected components leave them open. That is where integration becomes a security capability and an operating cost.

8DB puts protected storage and authenticated PQ exchange inside an embeddable database. Its supported operations give the team a common place to enforce and inspect that protection. The opportunity grows when more useful work can share the same information and authority.¹³⁶

Put the engine where the application runs

A database architecture reaches only as far as the applications that can use it. A watch collecting measurements, a phone working offline and a server coordinating a fleet have different resources. Requiring a separate database service at every endpoint changes what the team can deploy.

8DB runs inside the application. Its published platform coverage includes iOS, watchOS, macOS, Windows, Linux and Android. That gives builders a common engine to consider across watches, phones, tablets, desktops and servers, with workloads sized for each device.¹⁵

Embeddability expands where protected local work can happen. The buying question is which operations, resource budgets and exchange profiles fit each endpoint. Platform support and qualification of a complete cross-device workflow are separate checks.¹⁷¹⁵

Keep control when connectivity disappears

An industrial site can lose its connection while its machines keep running. A field team can still need yesterday’s records. A vehicle can collect information long before it can deliver it.

8DB’s tested core storage operations run in process without requiring an online external key-management or identity service. Protected local work can continue with the network disabled. Secret root material and governance context support local key derivation; the deployment still provisions and protects that trust material.³

Useful information can stay close to the people and machines that need it, under locally enforceable authority. Connectivity determines when nodes can exchange information. It need not determine whether a provisioned local store can protect and use its supported data.

There are credible alternatives here, too. SQLCipher supplies encrypted SQLite storage inside the application. Couchbase Lite supplies direct peer synchronization without a centralized cloud control point. Oracle and Db2 offer local keystores. 8DB’s value is the integration of local protection, authority and authenticated PQ exchange in its supported paths. A SQLCipher-based design would add a sharing and identity layer; a Couchbase Lite design should be assessed against the required PQ algorithms and intermediary trust boundaries. Offline operation alone does not settle that comparison.^8101112

Give the same information more uses

Consider a maintenance application. A technician needs a service history. An engineer needs sensor trends. A planner needs a map. An AI application needs similarity search across prior incidents.

Those are different questions about connected information. A fragmented implementation can turn them into separate databases, synchronization jobs and copies. Each copy brings work: access policy, encryption, retention, backup, recovery and reconciliation when something changes.

8DB’s omnimodal architecture treats data models as different ways to represent, index and query shared information. Its published native representations span records and documents, graphs and hypergraphs, dense and sparse vectors, time series, spatial structures, and media. A new question can use another projection without requiring another independently governed database.⁴¹⁶

The security benefit is fewer places where the same fact needs a new protection plan. When a workload fits the shared architecture, policy and provenance can stay with the information as applications use it in different ways.

The storage evaluator covers defined shapes and operations, including vectors, spatial work, directed edges and hyperedges. Media representation has format-specific coverage; transcription or semantic interpretation can require additional models. Evaluate the combination of data shape, useful operation, device and protection path. Broader local-storage coverage remains separate from the current lexical exchange profile.¹³¹⁶

Start with one information foundation. Add a specialist system where the workload earns the additional integration and operating cost.

SurrealDB already combines multiple data models with embedded deployment. A feature list saying “documents, graphs and vectors” therefore leaves out the more consequential comparison: which useful operations share protection, authority and recovery in the chosen deployment. For 8DB, the opportunity is to carry more of that work within the protected data architecture, reducing the separate copies and integrations the application actually needs.⁴¹³

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

The data you keep for twenty years may need more than one generation of cryptography. Standards evolve. Implementations develop weaknesses. Your organization changes policy. The next transition will arrive with years of information already stored.

Choose the database for how it changes protection, as well as how it protects data today. NIST treats cryptographic agility as an ongoing capability, including replacing protection for stored data and managing existing signatures.¹⁷

The migration command is only one part of the job. Someone must identify old protection, stop adding to it, preserve authorized access during the transition, recover from interruption and account for copies that remain. Across device stores, server databases and analytical replicas, that becomes a coordination problem.

Oracle supports online tablespace algorithm rekeying and resuming interrupted conversions. Its procedure still requires auxiliary storage and coordination with master-key operations. SQLCipher supplies migration tools, but non-default legacy settings require manual export-based migration; its documentation assigns upgrade detection and invocation to the application.²⁰²¹

These are capable tools. Their boundaries determine how much work remains with your team. A successful server rekey does not upgrade a separate phone database, reconcile its exports or establish that every application can read the new protection.

8DB brings more of that work into the engine’s lifecycle. Versioned ciphertext lets its registry select the implementation needed to read a record. Supported old and new versions can coexist, with the new version selected for writes. That gives applications a common dispatch path while historical data is being retired. Configured controls can stop new use of the old algorithm while permitting controlled migration.⁶

Changing tomorrow’s writes does not upgrade yesterday’s records. 8DB prepares and verifies a replacement generation before activation. Current-authority checks govern migration and managed recovery; managed-copy accounting and dataset reports make remaining obligations inspectable. The operator can connect the work performed to the evidence of what changed.⁶¹⁸

Vendor-run tests migrated a 100,000-record lexical store from HKDF-SHA-256 to HKDF-SHA-384 while retaining AES-256-GCM-SIV, including interruption, resume and exact-content recovery. Read availability varied across runs: some missed the declared one-second deadline, and deliberate process outages were accounted for separately. The result demonstrates this implemented migration path; additional algorithms and deployments require their own validation.¹⁹

Migration still consumes processing and storage in 8DB. Its architectural advantage is a more integrated operating task: version handling, controlled transformation, recovery and reporting inside the protected data system. Buyers should measure both the resource cost and the integration work their team would otherwise own.

Omnimodality and embeddability strengthen that value. When several application views share one governed information foundation, fewer independent stores need separate transition plans. When the same engine fits local and server deployments, teams can reuse its lifecycle mechanisms. The benefit grows with the supported work consolidated: fewer handoffs, less duplicated migration logic and a clearer account of what remains.

The investment is in data you can keep using as its protection evolves.

What to demand from a post-quantum database

Ask where protection ends, where costs are paid, which data and devices the engine can serve, and how stored information survives the next cryptographic transition. Compare the complete configuration required to deliver, use and maintain an authorized, durable record. Count services, custom code, stored structures and actual network operations on the same terms.¹⁵⁹¹⁷

For a cross-model application at the edge, 8DB’s opportunity is substantial: protected local storage, authenticated exchange, more uses for the same information and an inspectable protection lifecycle within an embeddable data architecture. The value grows when this lets a team remove a copy, a service dependency or an integration it would otherwise have to operate.

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

Tell us where your data starts, where it needs to go and who must never be able to read it. We’ll identify a supported starting point and propose an evaluation covering your data shapes, devices, protection lifecycle and complete cost.

Map your protected data workflow with 8Braid.

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; no universal consolidation or specialist-performance superiority is asserted here.

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. Describes 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.

Published and discussed

GitHub ↗