zkDB vs FHE vs TEE: a decision tree for architects

CTOs evaluating privacy-enhancing technologies (PETs) often discover, late in procurement, that the categories they have been asked to choose between answer different questions. This is the single most expensive misunderstanding in modern data architecture.

This article disambiguates the five technologies enterprises actually compare, and gives a decision tree usable in a single architecture meeting.

The five technologies

• zkDB (Zero-Knowledge Database) — proves a query result was correctly computed on a committed dataset, without revealing the rows.
• FHE (Fully Homomorphic Encryption) — allows computation directly on encrypted data; the compute provider never sees plaintext.
• MPC (Secure Multi-Party Computation) — a protocol where N parties jointly compute a function without revealing their inputs to each other.
• TEE (Trusted Execution Environment) / Confidential Computing — hardware-isolated enclaves (Intel SGX/TDX, AMD SEV-SNP, NVIDIA H100 CC) where data is decrypted only inside the enclave.
• DP (Differential Privacy) — a mathematical framework for adding calibrated noise to results so that no individual record can be identified.

The core distinction nobody states clearly

Most PET marketing collapses two orthogonal properties:

• Confidentiality — who can see the data during the computation?
• Verifiability — who can be convinced the computation was performed correctly?

These are different. A TEE provides confidentiality from the host OS but does not, by itself, produce a transferable mathematical proof that the right computation ran — you trust the chip vendor's attestation. FHE provides confidentiality during compute but produces an encrypted result that the requester cannot verify was computed correctly without additional machinery. MPC distributes confidentiality among parties but does not prove correctness to a non-participating third party.

zkDB is the only one of the five that natively answers "prove to me that the answer is correct," and does it with a small, transferable artifact.

The decision tree

                Need to ANSWER queries on private data?
                            │
                ┌───────────┴───────────┐
                │                       │
      Need verifier to be          Need result to be
      convinced of correctness?    statistically anonymous?
                │                       │
      ┌─────────┴─────────┐             │
      │                   │             ▼
     YES                  NO       ◆ Differential Privacy
      │                   │
      ▼                   │
◆ zkDB                    │
(transferable proof,      │
 no rows revealed)        │
                          ▼
                Confidentiality of compute matters?
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
     From host?      From peers?    Cryptographic, no
     ◆ TEE           ◆ MPC          hardware trust?
                                    ◆ FHE

The comparison table

When to use each

Use zkDB when:

• A third party needs to be convinced of the correctness of a query result — regulator, counterparty, auditor, end-user, court.
• The proof needs to survive the session — be filed, archived, re-verified years later, transferred to a different verifier.
• The answer itself is non-sensitive but the underlying data is. (If the answer is sensitive, layer DP.)
• You are willing to pay a one-time prover cost in exchange for permanent, transferable evidence.

Classic examples: regulatory capital ratio submissions, clinical trial endpoint aggregations, ESG/carbon disclosures, public statistics, AI training-set membership proofs.

Use FHE when:

• You need to delegate computation to a party you do not trust with the inputs.
• The computation surface is narrow and well-defined (aggregations, simple ML inference, set intersections).
• You can absorb the order-of-magnitude performance cost — usually because the alternative is "do not compute at all."

Classic examples: encrypted feature aggregation in customer segmentation, encrypted inference at the edge.

Use MPC when:

• A consortium of mutually-distrusting parties needs to compute a joint function over their inputs.
• No single party can or will hold all inputs.
• The function and the parties are stable over time.

Classic examples: cross-bank fraud signal aggregation, joint clinical research between hospitals, multi-party key management.

Use TEE / Confidential Computing when:

• You need throughput and plaintext semantics inside the enclave — your existing software runs largely unchanged.
• The threat model is the host operating system (cloud provider, malicious admin).
• You are comfortable rooting trust in the chip vendor's attestation chain (Intel, AMD, NVIDIA).

Classic examples: confidential containers in regulated multi-tenant cloud, sealed key services, GPU-accelerated private inference.

Use Differential Privacy when:

• You are publishing statistics or aggregates to a population.
• Individual records must remain statistically indistinguishable in the released output.
• You can budget an epsilon parameter (the privacy-vs-accuracy knob) over the life of the dataset.

Classic examples: US Census 2020, OpenAI public usage statistics, large-scale survey results.

Why these are not "either / or"

Most real engagements compose multiple technologies:

• zkDB + DP: prove that the published statistic was derived from the committed dataset under the agreed DP mechanism. The DP guarantees the answer is privacy-safe; the zkDB proves the process was honest.
• zkDB + TEE: the prover runs inside a TEE so that even the operator's own staff cannot peek at the witness while a proof is being generated. The proof guarantees external verifiers correctness; the TEE guarantees internal confidentiality.
• MPC + zkDB: an MPC consortium computes a joint statistic; each participant contributes a zkDB proof that their share was correctly derived from their committed dataset. The MPC provides confidentiality among peers; the zkDB provides verifiability to the regulator who consumes the result.
• FHE + zkDB: encrypted inputs to an FHE computation are committed under zkDB; the output is accompanied by a proof that the FHE computation was performed on the committed inputs.

The right architectural question is not "which one?" — it is "which combination, and at which layer?"

Engagement note

Most enterprise PET decisions go wrong at the comparison stage. We routinely advise on architectures that combine three of the above technologies for different reasons in different layers of a single pipeline. If your team is trying to choose, the choice you actually need to make is probably narrower than you think. Request a briefing →