FHE Benchmark: Encrypted Vector Search in 165ms

August 5, 2026

Every company working on fully homomorphic encryption publishes benchmarks. Very few of them can be compared to each other.

The reason isn’t dishonesty. It’s that the numbers are usually measured differently. One vendor reports a single ciphertext multiplication. Another reports a full pipeline, but at a lower security level. A third reports GPU results against a CPU baseline they wrote themselves. Each number is accurate on its own terms, and none of them line up. If you’re evaluating whether encrypted search is fast enough for your product, that’s a hard place to start from.

So alongside our own measurements, we submitted to a benchmark we don’t control.

The benchmark

HomomorphicEncryption.org — the standards body behind the FHE security standard — runs a public benchmarking platform. It defines fixed workloads, fixed parameters, fixed security levels, and a reference CPU implementation that every submission is measured against. You submit your code. It gets run. The results go on a public leaderboard next to everyone else’s.

The workload we targeted is Fetch-by-Similarity: given an encrypted query vector, find the nearest neighbors in an encrypted vector database and return the matching payloads. Count matches, then fetch them. That closely mirrors the retrieval step of a RAG pipeline — which is why we cared about it.

Two instance sizes, both at 128-bit security:

  • Small — 50,000 vectors × 128 dimensions
  • Medium — 1,000,000 vectors × 256 dimensions

The numbers

We ran on a single NVIDIA GeForce RTX 5090.

Medium (1M × 256) Small (50K × 128)
Count matches 165 ms ~15 ms
Fetch payloads 275 ms —
vs. CPU reference ~5,100× / ~4,300× faster 3,300–4,800× faster
vs. best prior GPU submission — 19× faster

Server-side computation over a million-vector encrypted database, from query to retrieved payloads, comes in under 0.3 seconds.

The last row is the one we’d point at first: 19× faster than the best previously submitted GPU implementation, on the same workload, the same parameters, and the same platform.

 

The number that gets less attention

FHE has a second cost that’s discussed less often than latency: ciphertext expansion. Encrypted data is larger than plaintext, sometimes by a wide margin, and if the encrypted index doesn’t fit in memory, latency stops being the binding constraint.

On the Medium instance, the CPU reference implementation produces a 171.5 GB encrypted database. Ours is 4 GB.

That’s roughly a 43× reduction, and it changes the deployment picture. A 4 GB index fits comfortably on a single GPU, which is a different operational conversation than provisioning for 171.5 GB. Encrypted queries are 64 KB, small enough that network transfer isn’t the dominant cost.

Latency gets the headline. Size often determines what you can actually ship.

 

No specialized hardware

The RTX 5090 is a consumer graphics card — not an H100, not an FPGA cluster, not a custom FHE accelerator.

That matters for planning. A common view has been that FHE becomes practical once dedicated silicon arrives, which makes adoption contingent on a hardware roadmap you don’t control. These results are one data point suggesting the timeline is shorter than that for this class of workload: it runs today on hardware that’s widely available.

 

What the server sees

Nothing, and it’s worth stating precisely what that means.

Throughout the computation, the server never sees the stored vectors, the query, or which results matched. There is no decryption step — not at rest, not in transit, not during search. Similarity is computed on ciphertext and returned as ciphertext. Only the key holder can read the scores.

This is a different guarantee from “the data is encrypted.” Encrypted-at-rest systems decrypt in order to search. Customer-managed keys change who controls the key, not whether plaintext exists on the server. Confidential computing relocates trust to a hardware enclave — an assumption that work like TEE.fail has shown can be attacked. Here, confidentiality rests on lattice-based cryptography rather than on an enclave holding the line.

 

Where this lands in practice

Encrypted RAG. An enterprise knowledge base can be embedded and searched without the retrieval layer holding readable text. Sub-300ms server-side leaves room for the rest of the pipeline in an interactive assistant.

Biometric matching. Fingerprint and face templates can’t be reissued after a breach. Matching over ciphertext means the templates stay encrypted on the server.

Regulated analytics. Healthcare and financial workloads where the question isn’t whether you trust your cloud provider, but whether you’re permitted to hand over plaintext at all.

Fetch-by-similarity is the retrieval step of a RAG system rather than the whole pipeline, and the benchmarking platform hosts other workloads covering different shapes of computation — we’ll be submitting to those as well.

 

Summary

  1. FHE benchmarks are hard to compare across vendors because they’re measured differently. Standardized third-party benchmarks address that, so we submitted to one.
  2. On HomomorphicEncryption.org’s Fetch-by-Similarity workload at 128-bit security, on a single RTX 5090: 165 ms to count matches and 275 ms to fetch payloads over one million encrypted 256-dimensional vectors.
  3. That’s roughly 5,100× and 4,300× faster than the CPU reference — and on the smaller instance, 19× faster than the best previously submitted GPU implementation.
  4. The encrypted database is 4 GB where the reference is 171.5 GB. Queries are 64 KB.
  5. No specialized hardware — a consumer GPU.
  6. The server never sees the data, the query, or the results.
  7. Both the results and the submission code are public, and reproducible.

References

These results come from the same engine behind enVector, our confidential vector database. enVector runs similarity search directly over CKKS-encrypted embeddings — nothing is decrypted at rest, in transit, or during search — and it’s model-agnostic, so it fits into an existing RAG pipeline without changing your embedding or generation stack.

enVector is available on Google Cloud Marketplace, so you can deploy it with Google Cloud billing and procurement and draw down an existing Google Cloud commit. It’s cloud-neutral by design and also runs on AWS, Azure, and OCI. See the live demo at heaan.land, or start on the Marketplace from $0.01/hour.

 

← Back to blog