If you have evaluated fully homomorphic encryption and walked away from it, you had to make that call. The performance numbers are not a temporary limitation waiting on faster chips. The problem is architectural; and a hardware upgrade will not fix it.
Traditional Fully Homomorphic Encryption (FHE) operates 100 to 10,000 times slower than plaintext operations. A simple query that takes milliseconds on an unencrypted database can take minutes or hours under FHE. Complex joins become practically impossible. Interactive analytics on a production database are out of the question.
The security objective that FHE was trying to achieve is the right one: compute on encrypted data without decrypting it. That is exactly what needs to happen. The question is whether there is an architecture that delivers that outcome without the performance penalty that makes FHE unusable at enterprise scale. There is.
Why Fully Homomorphic Encryption Is Too Slow: The Architecture Problem
Traditional FHE is built on lattice-based cryptography (schemes like BGV, BFV, CKKS, and TFHE). Every computation on encrypted data requires managing complex polynomial arithmetic across large ciphertext representations, and each operation injects noise that must be periodically refreshed through an expensive bootstrapping step. The ciphertext expansion alone is significant; encrypted data in a traditional FHE system is typically many times larger than the original. Every query, every join, every aggregation carries that overhead through every operation.
The computational demands typically require specialized hardware acceleration, often including GPUs or FPGAs, with corresponding increases in hardware, power, and cooling costs over standard database infrastructure. The total cost of ownership for a traditional FHE deployment runs materially higher than that of conventional infrastructure.
The HomomorphicEncryption.org consortium, which includes participants from Microsoft, Google, IBM, and major research universities, has been working on FHE performance for years. The improvements are real and ongoing; the performance gap to plaintext operations remains orders of magnitude. For production enterprise databases running interactive workloads, traditional FHE is not a near-term answer.
Which means the question becomes: is there a way to achieve the same security outcome through a different cryptographic approach?
What the Security Objective Actually Requires
The gap that FHE was designed to close is real and consequential. As we covered in The Encryption At Rest Myth, production databases are almost never truly at rest. From the moment a database service starts, data exists in an active in-use state. Traditional encryption protects data on disk and in transit. It protects nothing once the application is running. That is the window every serious breach exploits.
The requirement is not FHE specifically. The requirement is that data never exist in cleartext during processing. That is a security outcome. FHE is one approach to achieving it. It happens to be the approach that carries prohibitive performance penalties at enterprise scale.
A different cryptographic architecture that achieves the same outcome without those penalties is not a compromise. It is a better solution to the same problem.
Continuous Encryption: A Different Architecture, the Same Outcome
At Donoma, we’ve been focused on this problem to meet our own obligations for securing sensitive data. We designed an encryption platform called Seshat that combines symmetric and asymmetric primitives with design principles drawn from lattice cryptography, and an efficient query transformation layer. Seshat processes queries through a secure query engine that preserves SQL semantics while keeping the data encrypted throughout. The data never decrypts for processing. The cryptographic approach is fundamentally different from traditional FHE; the security outcome is the same.
The performance difference is not marginal. Where traditional FHE turns simple queries into seconds-to-minutes operations and renders complex joins and analytical workloads impractical, Seshat keeps encrypted queries within operationally usable ranges for interactive enterprise workloads. In practice, Seshat operates at near-native query speeds. The latency overhead is a small multiplicative factor on the plaintext baseline, scaling proportionally with workload size rather than blowing up nonlinearly. A query that completes in one second on plaintext data completes in a fraction more on encrypted data; a five-second query in a fraction more than that. The gap with FHE spans orders of magnitude, and it is the consequence of two fundamentally different cryptographic architectures applied to the same problem.
The infrastructure requirements are equally different. Seshat runs on standard CPU architecture with no specialized GPU or FPGA hardware, and its storage overhead is a small fraction of what lattice-based FHE schemes impose. Total cost of ownership remains close to standard database infrastructure rather than a large multiple above it.
What Continuous Encryption Actually Enables
The practical consequence of encrypted query processing that operates at usable speeds is that continuous encryption can move from a specialized capability into routine deployment for the workloads where exposure during processing carries the most risk: regulated data, classified environments, and any production database where in-use protection has been deferred because the only available approach was unworkable.
For AI and machine learning workloads, this matters in ways that are just beginning to be understood. RAG pipelines and LLM inference currently require that sensitive data be decrypted into the inference environment; creating an exposure window at precisely the point where data value is highest. Continuous encryption closes that window. Sensitive data can power AI workflows without ever existing in a state where it can be captured.
For Zero Trust architectures, it addresses the gap that perimeter and identity controls cannot close. As we covered in Perimeter Security Is Not Enough, an attacker who has cleared every identity check still finds nothing usable if the data remains encrypted during processing. The breach succeeds at the access layer; it fails at the data layer.
For government and coalition environments, it enables cross-domain and inter-agency data sharing that was previously architecturally impossible without creating decryption exposure. The architecture that applies in a federal context is the same one that applies across healthcare, financial services, and any enterprise managing sensitive data under regulatory obligations. The use case varies. The underlying requirement does not.
The deployment path is also materially different from what organizations encountered when evaluating traditional FHE. Seshat integrates with existing applications through an API, with the underlying encryption and key management components deployed alongside. Application integration requires only minor modifications and no database migration; deployment is measured in months. The full deployment picture for enterprise environments is covered in Unlocking Mission Success Through Encrypted Data Processing.
The Practical Question for CISOs and CTOs
If you evaluated FHE and concluded it was too slow, the conclusion to draw is not that encrypting data in use is impossible. The conclusion is that the specific cryptographic approach you evaluated carries performance penalties that make it unsuitable for today’s environment.
The security gap it was trying to address is still open. Your databases are still decrypting data during active processing. That window is still the attack surface that sophisticated threats target. The evaluation that concluded FHE was too slow did not close that gap; it just deferred it.
The question worth asking now is whether a continuous encryption architecture that operates at enterprise scale changes the calculus. The performance numbers are real. The infrastructure requirements are standard. The integration path does not require a re-architecture. The security outcome is the same one FHE was promising.
The solution is ready. The business case is clear. The time for action is now.
If you evaluated FHE and want to understand what a continuous encryption architecture looks like against your specific database environment, book a solution briefing with the Donoma team today.
Frequently Asked Questions
Why is fully homomorphic encryption too slow for enterprise use?
Traditional Fully Homomorphic Encryption (FHE) imposes latency penalties of orders of magnitude over plaintext operations, even with hardware acceleration. A simple query that takes milliseconds on an unencrypted database can take minutes or hours under traditional FHE. Complex joins, aggregations, and full-text search become practically impossible. The performance cost is architectural, not incremental; it is a fundamental characteristic of how lattice-based FHE schemes operate, including the noise growth and bootstrapping that every computation accumulates.
What is the difference between fully homomorphic encryption and continuous encryption?
Traditional homomorphic encryption relies on lattice-based schemes (BGV, BFV, CKKS, TFHE) whose polynomial arithmetic and bootstrapping impose massive computational overhead. Continuous encryption, as implemented in Seshat, uses efficient query transformation layer that enables operations on encrypted data at speeds suitable for interactive workloads. The security outcome is the same: data never decrypts for processing. The performance and infrastructure requirements are fundamentally different.
What are the real-world performance differences between traditional FHE and Seshat?
Seshat operates at near-native query speeds. The latency overhead is a small multiplicative factor on the plaintext baseline; a query that completes in one second on plaintext data completes in a fraction more on encrypted data, and a five-second query in a fraction more than that. Overhead scales proportionally with workload size rather than blowing up non-linearly. Compared with traditional FHE, the performance gap spans orders of magnitude across the operations that matter in production: simple queries, complex joins, and analytical workloads. The gap is the difference between a technology that is theoretically interesting and one that is operationally deployable on encrypted production data.
Does Seshat’s continuous encryption engine require specialized hardware?
No. Traditional FHE implementations typically require specialized GPU or FPGA acceleration, with corresponding increases in hardware, power, and cooling costs over standard infrastructure. Seshat runs on standard CPU architecture with no specialized hardware requirements.
What database operations does continuous encryption support?
Seshat supports complex SQL operations on encrypted data including joins, aggregations, pattern matching, full-text search, nested queries, and calculation operations. Traditional FHE is practically limited to simple operations or requires extensive preprocessing. Seshat maintains full SQL semantics while preserving encryption throughout the operation, enabling interactive query performance on encrypted production databases.
Can Seshat’s continuous encryption be deployed on an existing database without re-architecture?
Yes. Seshat integrates with existing applications through an API, with the underlying encryption and key management components deployed alongside. Platform integration is configuration-based: no recompilation or repackaging of the application stack is required. Query encryption is handled through a lightweight SDK that the application uses to issue encrypted queries; this is a scoped integration, not an application rewrite. Deployment is typically measured in months, not years, and does not require migration of data structures.
Additional Reading
- The Encryption At Rest Myth — Why the encryption your team is relying on stops working the moment your database goes live
- Perimeter Security Is Not Enough — How Zero Trust architecture still leaves a data-in-use gap that identity controls cannot close
- Unlocking Mission Success Through Encrypted Data Processing — How continuous encryption deploys in complex, high-sensitivity enterprise environments
