Skip to content

SYSTEM Cited by 2 sources

Atlas Queryable Encryption

Overview

Atlas Queryable Encryption is MongoDB's industry-first searchable encryption scheme — a cryptographic + server-side index construction that lets applications run equality and range queries on fields that remain fully encrypted on the server. Decryption keys never leave the client. The server maintains encrypted indexes for the fields the application elects to query, and the matching is performed on the encrypted tokens — not on plaintext.

MongoDB's framing of the problem it solves:

"For decades, the trade-off has been brutal: to run a query, you had to decrypt your data on the server, exposing it to risk. Queryable Encryption — an industry-first searchable encryption scheme developed by MongoDB Research — breaks this paradigm."

(Source: sources/2025-09-25-mongodb-carrying-complexity-delivering-agility)

Why this is a notable break

Prior encryption-at-rest models — AWS KMS-backed volume encryption, transparent database encryption, even most field-level schemes — all share a structural limitation: the database process must have the plaintext to match predicates against it. A DBA, a compromised DB process, a side-channel against the DB VM, or a memory-dump attack therefore sees plaintext values during query.

Queryable Encryption breaks that: server-side indexes contain only cryptographic tokens; the plaintext never exists on the server. A compromised DB process or a rogue insider with server-side access cannot read the queryable field — only the client application, with the client-held decryption key, can.

Named supported operations

The 2025-09-25 post names two query-class supports:

  • Equality checks — {field: <value>} match, $in, $eq.
  • Range checks — $lt / $gt / between bounds on encrypted numeric / date fields.

Implicitly not covered by the public framing: arbitrary full-text search, regex, aggregations over encrypted fields, JOIN-like cross-field predicates. Those either require decrypting or are not supported.

Threat model fit

The cleanest fit is the compromised-server / untrusted-server model:

  • Rogue DBA / operator. Admin-level access to the DB host grants no plaintext access to encrypted fields.
  • Database-process exploit. A memory-disclosure bug in the DB process doesn't leak plaintext because plaintext is never in the DB-process memory.
  • Cloud-provider subpoena / legal compulsion. A cloud operator responding to lawful process on the database storage returns ciphertext only.

Weaker fit:

  • Compromised client. The client holds the keys; client-side malware defeats the scheme.
  • Side-channel on query patterns. Ciphertext-indistinguishability does not hide which documents the client queried — query volume + timing + access patterns can still leak information. Mainstream searchable-encryption constructions all have some leakage profile; MongoDB's published threat-model boundaries would be in the MongoDB Queryable Encryption docs, not in this manifesto post.

Role in MongoDB's defense-in-depth story

The 2025-09-25 post positions Queryable Encryption as the "What if someone gets in?" answer in its five-layer defense-in-depth framing — i.e. the primitive that ensures encryption survives a compromise of the earlier layers (authn/authz/network). Combined with architectural isolation — dedicated clusters — the attacker has to (a) breach isolation, (b) defeat authz, and (c) still not see plaintext, because keys live in the client.

Caveats

  • Performance cost not quantified in the source. Searchable encryption schemes pay some combination of larger ciphertext, more index entries, and costlier query-time operations; the manifesto post doesn't publish overhead numbers.
  • Not a silver bullet. Fields must be elected as queryable; fields queried in ways Queryable Encryption doesn't support (full-text, regex) still need a different strategy (Client-Side FLE + no server-side search, or plaintext + isolation).
  • Key management is the hard part. The scheme moves the secret-handling problem to the client; application teams still need to do envelope encryption, key rotation, and access control over keys. See concepts/cryptographic-shredding for the related key- deletion-as-data-deletion primitive.

Seen in

  • sources/2025-09-25-mongodb-carrying-complexity-delivering-agility — canonical wiki source; industry-first framing, query-class support (equality + range), client-held-keys invariant, role in MongoDB's defense-in-depth stance.
  • sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse — historical-narrative companion; names Queryable Encryption as "a revolutionary breakthrough" in the enterprise-readiness journey and calls out newly-added prefix / suffix / substring queries over encrypted fields (extending beyond equality + range); positions QE within MongoDB's compliance stack — ISO/IEC 27001, SOC 2 Type II, PCI DSS, HIPAA — as independent validation of the end-to-end security story.
Last updated · 200 distilled / 1,178 read