Post-Quantum Caching Is the Only Caching That Will Exist

There is a common misconception that post-quantum cryptography is a niche concern. That it affects a small number of systems in government and defense. That most organizations have years to prepare. That the transition will be gradual and optional.

Every part of that is wrong.

Post-quantum cryptography is not a feature. It is not an add-on. It is not a compliance checkbox for agencies with three-letter acronyms. It is the future state of all cryptography. Every key exchange, every digital signature, every certificate, every token, every session credential on every system on the internet will use post-quantum algorithms. Not because organizations choose to adopt them, but because the libraries they depend on will stop shipping anything else.

And when that happens, every cache that touches cryptographic material becomes a post-quantum cache. Whether it was built for it or not.

The Supply Chain Makes the Decision for You

OpenSSL 3.5 ships ML-KEM and ML-DSA as default algorithms. BoringSSL, the TLS library that powers Chrome and Android, already uses ML-KEM-768 for key exchange in production. AWS-LC, Amazon's cryptographic library, includes ML-KEM and ML-DSA in its default build. Go 1.24 added ML-KEM-768 to its standard library. Rustls ships post-quantum key exchange.

These are not experimental branches. They are the default configurations that ship with the next version of the library your application already uses. When you run apt upgrade or brew upgrade or rebuild your Docker image, the PQ algorithms arrive whether you planned for them or not.

The moment your TLS library upgrades, every TLS handshake your server performs generates ML-KEM ciphertexts. Those ciphertexts are 1,088 bytes instead of 32 bytes. They land in your session ticket cache. Your cache is now storing post-quantum key material. You did not choose this. Your dependency tree chose it for you.

There Is No "Classical-Only" Future

Some teams assume they can pin their cryptographic libraries to classical-only versions indefinitely. This is not viable for three reasons.

Security patches stop. When OpenSSL 3.4 reaches end of life, security patches stop. The only supported versions will be the ones that default to PQ algorithms. Running an unsupported TLS library in production is not a caching decision. It is a security incident waiting to happen.

Compliance mandates arrive. CNSA 2.0 is the US federal mandate, but it is not the only one. The EU's Cyber Resilience Act requires "state of the art" cryptography for products sold in Europe. PCI DSS 4.0 requires "strong cryptography" and will eventually define that to include PQ resistance. SOC 2 auditors are already asking about PQ migration plans. If you sell to enterprises, you will be asked. If you sell to government, you will be required.

Your customers upgrade before you do. Even if your servers run classical crypto, your clients will send PQ-protected requests. Chrome is already negotiating ML-KEM in TLS handshakes with every server that supports it. When a client sends a ClientHello with ML-KEM-768 key shares, your server either responds with PQ parameters or falls back to classical. The fallback works today. It will not work when browsers deprecate the fallback. At that point, your server either speaks PQ or it does not speak TLS.

What "Every Cache Becomes a PQ Cache" Actually Means

When the cryptographic transition completes, every piece of cached data that contains or is protected by cryptographic material will carry post-quantum key sizes. This is not limited to caches that explicitly store keys. It includes every cache that stores the output of a system that uses keys.

Session caches

Every session token carries the key material from the TLS handshake that created it. When that handshake uses ML-KEM, the session token grows by 1,056 bytes. One million sessions go from 96 MB to 4.49 GB of crypto material. The cache that held them comfortably now needs 47 times more memory for the same number of sessions.

API response caches

API responses that include signed data (JWTs, signed URLs, attestation receipts) carry ML-DSA signatures at 3,309 bytes each. A cached API response that included a 64-byte Ed25519 signature now includes a 3,309-byte ML-DSA signature. The response itself did not change. The cryptographic envelope around it grew by 52 times.

Certificate caches

OCSP stapling caches, certificate chain caches, and CT log caches all store certificates with signatures. When certificate authorities issue PQ certificates (and they will, because browsers will require them), every cached certificate chain carries ML-DSA or SLH-DSA signatures. A chain with three SLH-DSA-128f signatures adds 51 KB to every cached entry.

Object caches

Any object cache that stores encrypted or signed data inherits the PQ size increase. S3 presigned URLs with PQ signatures. Encrypted configuration blobs with ML-KEM-wrapped keys. Signed webhook payloads. Cached blockchain transactions (Ethereum is evaluating PQ signature schemes for account abstraction). The size increase propagates through every layer that touches cryptographic material.

The Cache Architectures That Survive

Not all cache architectures handle the PQ size increase equally. The determining factor is whether the cache's latency scales with value size.

Network caches fail gracefully, then fail completely. Redis, Memcached, and ElastiCache add latency proportional to value size. At classical key sizes, this overhead was negligible. At PQ key sizes, it becomes the dominant cost in the request path. A session validation that took 0.3ms at 96 bytes takes 0.6ms at 4,493 bytes. That doubling is survivable for a single lookup. But a request that hits the cache four times (session + JWT + rate limit + feature flag) goes from 1.2ms to 2.4ms of cumulative cache latency. At PQ key sizes with SLH-DSA signatures in the mix, the same four lookups can exceed 5ms. At that point, the cache is slower than many database queries, and its existence is a net negative on request latency.

In-process caches are size-independent. An in-process cache stores values in the application's address space. A lookup is a hash table read and a pointer dereference. There is no serialization, no TCP transfer, no deserialization. The latency is determined by the CPU's memory hierarchy, not by the value size. A 96-byte session token and a 49,856-byte SLH-DSA signature are both accessed at the same speed: one L1/L2 cache line load. On modern hardware, that is 20-40 nanoseconds.

This is the architectural divide that the PQ transition exposes. Caches that serialize and transfer data over a network degrade proportionally to PQ key sizes. Caches that store data in-process do not degrade at all. The PQ transition does not create this difference. It amplifies an existing difference until it becomes the deciding factor in cache architecture selection.

The Transition Is Not a Migration. It Is a Replacement.

When organizations migrated from MD5 to SHA-256, the hash outputs grew from 16 bytes to 32 bytes. A 2x increase. Cache infrastructure absorbed it without anyone noticing. When organizations migrated from RSA-1024 to RSA-2048, key sizes doubled. Again, absorbed without incident.

The post-quantum transition is not a 2x increase. It is a 25-779x increase depending on the algorithm. This is not the kind of change that existing infrastructure absorbs. It is the kind of change that forces architectural decisions. The organizations that recognize this early will build their cache layers for PQ sizes from the start. The organizations that do not will hit the wall when their library dependencies upgrade and their session caches suddenly need 47 times more memory and their request latency doubles overnight.

It Starts with One Command

brew tap h33ai-postquantum/tap && brew install cachee
cachee init && cachee start

Cachee runs in-process. 31 nanoseconds regardless of value size. 140+ Redis-compatible commands. CacheeLFU adaptive eviction in 512 KiB constant memory. Purpose-built for the payload sizes that post-quantum cryptography demands.

The transition is not coming. It is here. Chrome is negotiating ML-KEM today. Your cache is already storing post-quantum key material. The only question is whether your cache architecture was built for the sizes those keys produce.