MongoDB Queryable Encryption: Prefix, Suffix, and Substring Queries Are Now GA

Last week, we announced the general availability of prefix, suffix, and substring query support in MongoDB Queryable Encryption. These capabilities extend Queryable Encryption beyond equality and range queries, and they’re now fully supported for production workloads.

MongoDB Queryable Encryption is a groundbreaking, industry-first in-use encryption technology, developed by the MongoDB Cryptography Research Group. It enables customers to encrypt sensitive application data, store it in encrypted form in MongoDB, and run expressive queries on that encrypted data without decrypting it. The database never sees the data in plaintext.

Organizations can now run flexible text searches, matching partial names, words, or identifiers, on encrypted data in production—keeping the underlying information protected by design, under clearly defined security guarantees. That means stronger data protection, simpler compliance, and no need for workarounds like external search indexes. All with minimal code changes and no new infrastructure.

With support for prefix, suffix, and substring queries generally available in Queryable Encryption, MongoDB enables organizations to protect sensitive data throughout its lifecycle: at rest, in transit, and in use. As a result, teams can build secure, privacy-preserving applications without compromising functionality. Queryable Encryption is available at no additional cost in MongoDB Atlas, MongoDB Enterprise Advanced, and MongoDB Community Edition.

The challenge: Data is only protected until you need to use it

Most organizations store sensitive data: personally identifiable information (PII) like names and Social Security numbers, or protected health information (PHI) like medical records. Keeping that data secure while it sits in storage or moves across a network is well understood. Encryption at rest and in transit is standard practice today.

Querying that data is a different story. Traditional encryption makes data unreadable, which means a database can't search it without decrypting it first. Consider a healthcare provider that needs to find all patients with a diagnosis containing the word "edema"; without decrypting the records, the database can't search for that term.

To work around this, many organizations leave sensitive fields unencrypted or build external search indexes to enable the queries their applications need. Both approaches add operational overhead. Both also increase the risk of unauthorized access, right at the moment sensitive data is most exposed.

This gets harder under regulatory pressure. Standards like the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI-DSS), and General Data Protection Regulation (GDPR) increasingly expect organizations to demonstrate that sensitive data stays protected at every stage, not just at rest and in transit. Providing protection while data is actively in use is the piece most encryption approaches can't address.

To fully protect sensitive data and meet compliance requirements, organizations need a way to search encrypted data without decrypting it, and without sacrificing performance or adding new infrastructure.

Zero-exposure data protection

MongoDB Queryable Encryption is built to close this gap. It keeps sensitive data encrypted while it's actively being searched, the one stage that other encryption methods can't reach.

With Queryable Encryption, sensitive fields are never stored, transmitted, processed, or returned in plaintext, even on the database server itself. Queries are run on encrypted data. There's no decryption, and no window where the data is exposed.

This is possible because Queryable Encryption is built on a structured encryption scheme that keeps data encrypted during query processing on the server at all times. The scheme is fully open source and independently verifiable, not a black-box vendor claim. It's an industry-first approach: no other database technology offers this level of in-use encryption today, and it doesn't depend on specialized hardware like secure enclaves.

Organizations already trust Queryable Encryption to protect some of their most sensitive data. France's internal security forces (ANFSI) rely on it to secure sensitive records, backed by government-grade security review.

For teams handling PII, PHI, or other regulated data, this means one less place where sensitive information can be exposed, even from insiders with direct database access.

More expressive search, built in

Until now, Queryable Encryption has supported equality and range queries in general availability. That covered exact matches and bounded numeric lookups, but applications often need something more flexible: partial-name lookups, autocomplete, or partial-word filtering. With prefix, suffix, and substring queries now generally available, that gap is closed.

Here's what's now possible directly on encrypted fields:

• Prefix queries return documents where a field value starts with a specific sequence of characters. For example, finding all customers whose last names begin with "Mac."

• Suffix queries return documents where a field value ends with a specific sequence. For example, matching the last four digits of an encrypted Social Security number.

• Substring queries return documents where a specific sequence appears anywhere in the field. Substring search covers short, structured fields up to 50 characters, searching 2- to 6-character terms. For example, searching for "eng" within an encrypted job title field, matching both "Engineer" and "Engineering Manager."

• Range queries (existing) return documents where a field value falls within a specified lower and upper bound, like an encrypted salary range.

• Equality queries (existing) return documents where a field value matches exactly, like a specific encrypted email address.

These query types run through MongoDB's native query engine and drivers, the same ones used for every other query type. There are no external search indexes to stand up, no middleware to maintain, and minimal changes to application code. Teams get expressive, partial-match search on encrypted data using the same architecture they already run.

Compliance you can prove, not just claim

Meeting requirements like HIPAA, PCI-DSS, and GDPR means demonstrating that sensitive data is protected, not just asserting it. That's difficult when encryption claims can't be independently verified, and even harder when the claim doesn't cover data while it's actively in use.

Queryable Encryption gives compliance and risk teams a defensible answer. Its structured encryption scheme is fully open source, so the cryptography behind it can be independently reviewed rather than taken on faith. And because it protects data through query processing, not just at rest and in transit, it addresses a stage most compliance programs can't otherwise account for.

With prefix, suffix, and substring queries now generally available, that same evidence extends to more use cases: partial name and email search, partial word filtering in free-text fields, and partial ID matching. The result is fewer audit gaps and fewer fragmented tools to reconcile, whether workloads run on-premises, in a hybrid environment, or across multiple clouds.

What teams can now build

With prefix, suffix, and substring queries generally available in Queryable Encryption, here are some examples of what organizations can now achieve:

• PII search for compliance and usability: Regulations like GDPR and HIPAA mandate strict privacy of personal information. With prefix queries, teams can retrieve users by last name or email prefix while keeping the underlying data encrypted. That makes compliance easier without sacrificing search functionality.

• Partial word filtering on structured fields: Structured fields like diagnoses often require partial matching. With substring query support, teams can search an encrypted health condition field for a term like "diabet," matching both "diabetes" and "diabetic.”

• Secure ID validation: Identity workflows often rely on partial identifiers, like the last four digits of a Social Security Number, a National Insurance Number, or an Aadhaar Number. Suffix queries enable these lookups on encrypted fields without revealing full values, reducing the risk of data leaks in regulated environments.

• Case management for public agencies: Case numbers and reference IDs in public sector applications often follow structured formats. Prefix queries let agencies retrieve records using region- or office-based prefixes, like "NYC-" or "EUR-," without exposing sensitive case metadata.

Get started with Queryable Encryption

Prefix, suffix, and substring queries give teams a new level of flexibility in searching sensitive data without requiring them to choose between security and functionality. Whether the goal is meeting compliance requirements, reducing infrastructure complexity, or simply building better applications, these capabilities are ready for production today.

Prefix, suffix, and substring queries give teams a new level of flexibility in searching sensitive data. These new query types help protect sensitive data against unauthorized access and meet compliance requirements while reducing infrastructure and operational complexity.