Limitations

Read and Write Operation Support

The mongod only stores encrypted BinData and applies any aggregation expression or query operator specifying an encrypted field against the BinData value. While the expression or operator may support BinData fields, the resulting value may be incorrect or unexpected when compared to issuing that same expression or operator against the decrypted value. The mongod throws an error if the expression or operator does not support BinData values.

For example, consider a deterministically encrypted integer Salary. A query filters for documents where Salary is greater than 100000. The application explicitly (manually) encrypts the query value using deterministic encryption prior to issuing the query. The mongod compares the encrypted BinData value of 100000 to the encrypted BinData values stored in each document. While the operation returns successfully, the comparison of the BinData values may return a different result than the comparison of the decrypted integer values.

Automatic client-side field level encryption rejects read or write operations which would return incorrect or unexpected results when issued against an encrypted field. For complete documentation, see Read/Write Support with Automatic Field Level Encryption. Applications performing explicit (manual) encryption may reference the linked page as guidance for issuing read/write operations against encrypted fields.

Views

Queries against views on collections containing client-side field level encrypted values may return unexpected or incorrect results if either the underlying view aggregation pipeline or the query references encrypted fields. If creating a view on a collection containing client-side field level encrypted values, avoid operating on encrypted fields to mitigate the risk of unexpected or incorrect results.

While 4.2+ compatible drivers configured for automatic client-side field level encryption have validation for unsupported read and write operations, the underlying support library cannot introspect the view catalog to identify a given collection as a view. Applications therefore cannot rely on the automatic field level encryption validation to prevent unsupported queries against views on collections with encrypted fields.

For applications using explicit (manual) encryption to query a view on a collection containing encrypted values, consider constructing the query using only query operators with known normal behavior when issued against encrypted fields.

Collation

Client-side field level encryption does not respect user-specified collations or collection default collations. Field level encryption obscures the field value and prevents normal collation behavior. Collation-sensitive queries against encrypted fields may return unexpected or incorrect results.

While 4.2+ compatible drivers configured for automatic client-side field level encryption have validation for unsupported read and write operations, the underlying support library cannot introspect the collection catalog to identify the default collation. Applications therefore cannot rely on the automatic field level encryption validation to prevent querying on encrypted fields with collation defaults.

Unique Indexes

Unique indexes cannot guarantee uniqueness if the index key specifies any randomly encrypted fields.

Fields encrypted using the random algorithm always produce a different encrypted value given a specific input. The server considers each encrypted value unique even though the decrypted value itself is not unique. The collection can therefore contain multiple documents with duplicate decrypted values for a field with an index-enforced unique constraint.

While 4.2+ compatible drivers configured for automatic client-side field level encryption have validation for unsupported read and write operations, the underlying support library cannot introspect the index catalog to identify a given field as unique. Applications therefore cannot rely on the automatic field level encryption validation to prevent unique constraint violations on randomly-encrypted fields.

Shard Key

Specifying a shard key on encrypted fields or encrypting fields of an existing shard key may result in unexpected or incorrect sharding behavior.

While 4.2+ compatible drivers configured for automatic client-side field level encryption have validation for unsupported read and write operations, the underlying support library cannot introspect the sharding catalog metadata to identify shard key fields. Applications therefore cannot rely on the automatic field level encryption validation to prevent encryption of shard key fields.

Read/Write Query Support

Automatic client-side field level encryption supports a subset of commands, query operators, update operators, aggregation stages, and aggregation expressions. For complete documentation, see Read/Write Support with Automatic Field Level Encryption.