Why should you care?

Fraud and support still need to look up a customer by encrypted phone/email without exposing plaintext to the database server.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// Conceptual workflow (driver + crypt shared library + KMS)
// 1) Create encrypted fields map for users.phone
// 2) Auto-encryption MongoClient encrypts on write / decrypts on read
// 3) Queries look normal in app code:
db.users.insertOne({ email: "a@x.com", phone: "9999999999" })
db.users.find({ phone: "9999999999" })
// On disk / in mongosh without keys you see binary ciphertext, not the phone

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• The driver encrypts phone before the server sees it.
• Encrypted indexes make equality find work.
• Without keys, admins see BinData.
• Setup needs KMS, schema map, and the crypt shared library — follow current Atlas QE docs for your version.

Practice next

1. Read Atlas Queryable Encryption quick start for your language.
2. Classify one field (phone) for QE in a sandbox.
3. Insert and find by phone through the encrypting client.
4. Add email as a second encrypted field.
5. Compare CSFLE vs QE capabilities for your needs.

Remember

QE encrypts fields but keeps some queries working. Keys live in KMS, not in Mongo documents. Use for high-sensitivity lookup fields.

Lookup by encrypted mobile

Support finds accounts by phone without the DB storing plaintext mobiles.

Outcome: Breach of disk backups does not leak raw phone numbers.