MongoDB Queryable Encryption lets specific document fields be queried on the server without the server ever seeing their plaintext values — a fundamentally different security model from field-level encryption, which requires decryption before any server-side filtering can happen. The distinction matters for compliance contexts where the database host, DBA access, or cloud infrastructure staff must be excluded from seeing sensitive data, even while the application queries that data.

Situation

Most encryption-at-rest and field-level encryption (FLE) schemes protect data from attackers who steal storage media or backups. They do not protect data from someone with direct database access — a DBA with credentials, a cloud provider with storage access, or an attacker who compromises the database host. Encrypted at rest, but decrypted in memory when any query touches the field.

MongoDB Queryable Encryption (QE), generally available in MongoDB 7.0 with range query support expanded significantly in 8.0, changes that model. Specific document fields are encrypted at the client before they reach the MongoDB server. The server stores ciphertext. When the application queries those fields, it sends an encrypted query token; the server evaluates the query against encrypted data using a deterministic scheme that does not require the server to decrypt the field. The server returns matching documents, still encrypted. Only the client — with access to the encryption keys — can read the plaintext.

This means DBAs, MongoDB Atlas operations staff, and anyone with direct database access see only ciphertext for encrypted fields. The data is not just protected at rest; it is protected from privileged infrastructure access during normal operation.

The Problem

The failure mode for teams new to QE is query type mismatch. Queryable Encryption does not support arbitrary query patterns. The server can only evaluate queries that the underlying cryptographic scheme supports: equality (deterministic encryption, GA in MongoDB 7.0) and range (expanded in MongoDB 8.0 with prefix and suffix query support). The server cannot run regex, text search, full-document comparison, or most aggregation pipeline operations on QE-encrypted fields without decryption.

A team that implements QE on a sensitive field and later discovers that a new feature requires a case-insensitive text search or a LIKE-equivalent pattern on that field is stuck: the field is encrypted in a way that only equality and range queries can be evaluated server-side. Text search falls back to requiring application-layer filtering — fetch all documents, decrypt, filter in memory — which is functionally correct but operationally expensive at scale.

Core Concept

Queryable Encryption requires three components: a MongoDB driver with libmongocrypt support (6.0+), a key management configuration, and a schema that identifies which fields are QE-encrypted and which query type each supports.

flowchart TD
    Client["Application Client — Holds Keys"] -->|Encrypts data with DEK| Token["Encrypted Query Token"]
    Token -->|Sends token| Server["MongoDB Server 8.0"]
    Server -->|Evaluates ciphertext| Matches["Matched Encrypted Documents"]
    Matches -->|Returns ciphertext| Client
    Client -->|Decrypts with DEK| Plaintext["Plaintext Result"]

Required components:

ComponentPurpose
MongoDB driver with libmongocryptClient-side encryption and decryption
Customer Master Key (CMK)Root key, stored in KMS (AWS KMS, GCP KMS, Azure Key Vault, KMIP, or local for dev)
Data Encryption Key (DEK)Per-field key, encrypted by CMK and stored in a key vault collection
Encrypted fields mapTells the driver which fields to encrypt and what query types they support

QE vs standard FLE:

Standard FLEQueryable Encryption
Server-side queriesNot supported — client must decrypt before filteringSupported for equality and range query types
Storage formatDeterministic or random encryptionDeterministic (equality) or range-scheme encryption
Who can queryClient with key access onlyServer evaluates; client decrypts results
Supported queriesAny (post-decryption)Equality (GA, 7.0), range (expanded in 8.0)

Supported query types in 8.0:

MongoDB 8.0 expanded range query support to include prefix range, suffix range, and inequality queries on QE-encrypted fields. The types that remain unsupported for server-side evaluation include regex, text search, $elemMatch on nested QE fields, and most aggregation expressions that operate on field content.

Setting up QE (schema-level declaration):

// Encrypted fields map — specified at collection creation
const encryptedFieldsMap = {
  "fields": [
    {
      path: "ssn",
      bsonType: "string",
      queries: [{ queryType: "equality" }]
    },
    {
      path: "salary",
      bsonType: "int",
      queries: [{ queryType: "range", min: 0, max: 1000000 }]
    }
  ]
};

The encryption and decryption happen transparently in the driver via the ClientEncryption API. Queries against encrypted fields use the same MongoDB query syntax — the driver translates them to encrypted tokens before sending to the server.

In Practice

MongoDB Queryable Encryption was announced as Generally Available in MongoDB 7.0, with the GA announcement documented in the MongoDB 7.0 release notes and the QE documentation available in the MongoDB Manual (chapter “Queryable Encryption”). The expansion of range query support in MongoDB 8.0 is documented in the MongoDB 8.0 release notes (October 2024) and the Queryable Encryption compatibility page.

The documented pattern is that QE-encrypted fields cannot use standard B-tree indexes. As stated in the MongoDB QE manual, encrypted fields use a special metadata index structure managed by the QE subsystem, not a standard index that appears in db.collection.getIndexes().

Where It Breaks

ScenarioWhat breaksWhy
Application adds regex or text search on QE fieldQuery cannot run server-sideQE encryption scheme does not support text evaluation
Range query on QE field without range query type configuredError at query timeField configured for equality-only QE cannot process range queries
Key management in dev mode in productionSecurity model brokenLocal provider gives all server-side access to key material

What to Do Next

  • Problem: Teams implement QE on sensitive fields and later discover that new query types — text search, regex, complex aggregations — cannot run server-side against QE-encrypted data, requiring expensive application-layer workarounds.
  • Solution: Map every query pattern required for each sensitive field before implementing QE; use QE only for fields where equality and range queries are sufficient; keep non-queryable sensitive fields on standard FLE or separate encryption.
  • Proof: Test all application query patterns against the encrypted field in staging before deploying; any unsupported pattern fails at query execution time, not at configuration time.
  • Action: This week, document the required query types for each sensitive field your application needs to protect — equality, range, or open-ended — and verify that QE’s supported query types cover them before committing to the encryption scheme.

Queryable Encryption solves a real problem — privileged infrastructure access to plaintext sensitive data — but it imposes real query constraints. Understanding those constraints before schema design is the difference between a compliance win and a schema migration at the worst possible time.