Distributed transactions, which extend multi-document ACID guarantees from replica sets to sharded clusters, give customers an easier way to address a complete range of use cases by enforcing transactional guarantees across highly scaled, global applications. Field Level Encryption enables users to have encrypted fields on the server—stored in-memory, in system logs, at-rest and in backups—which are rendered as ciphertext, making them unreadable to any party who does not have client access or the keys necessary to decrypt the data. The Kubernetes control plane allows users to have full management over their MongoDB deployment for a consistent experience anywhere, including on-premises infrastructure, private and hybrid cloud, or public cloud.

“When we founded MongoDB, we wanted to give developers an easier way to work with data - wherever it lived in the stack,” said Eliot Horowitz, CTO and co-founder, MongoDB. “To be able to provide great new features that will make them more productive so they can spend less time wrestling with data and more time building great applications is extremely gratifying. Most importantly, these features work and feel like the tools they are already used to so they will experience a vastly improved database experience with a short learning curve.”

Distributed Transactions

MongoDB introduced multi-document ACID transactions in the release of MongoDB 4.0, providing a consistent view of data across replica sets and enforcing all-or-nothing execution to maintain data integrity. Combined with the power of the document model and its distributed systems architecture, developers can easily modernize existing legacy apps and build new transactional services. Distributed Transactions maintain an identical syntax to the transactions introduced in MongoDB 4.0. They are multi-statement and enforce snapshot isolation, making them familiar to any developer with prior transaction experience. The API and implementation is consistent whether executing transactions across documents, collections and databases in a replica set, or across a sharded cluster. Full atomicity is maintained – if a transaction fails to commit on one shard, it will abort on all participant shards.

The Next Level in Enterprise-Grade Security

MongoDB 4.2’s implementation of Field Level Encryption is a different and more comprehensive approach than column encryption used in legacy, relational databases. It is totally separated from the database, transparent to the server and handled exclusively within the MongoDB drivers on the client. Most databases handle encryption on the server-side, which means data is still accessible to administrators who have access to the database instance itself, even if they have no client access privileges. Field Level Encryption changes that.

Advantages of MongoDB Field Level Encryption include:

• Automatic, transparent encryption: Application code can run unmodified for most database read and write operations. Other client-side approaches require developers to modify their query code to use the explicit encryption functions and methods in a language SDK.
• Separation of duties: System administrators who traditionally have access to operating systems, the database server, logs, and backups cannot read encrypted data unless explicitly given client access along with the keys necessary to decrypt the data.
• Regulatory Compliance: Facilitate compliance with “right to be forgotten” requests in privacy regulations such as GDPR – simply destroy the customer key and the associated personal data is rendered useless.

“We partnered with two of the world’s leading authorities on database cryptography, including a co-author of the IETF Network Working Group Draft on Authenticated AES encryption, to develop Field Level Encryption,” said Lena Smart, CISO, MongoDB. “Drawn from academia and industry, these teams have provided expert guidance on MongoDB’s Field Level Encryption design and reviewed the Field Level Encryption software implementation.”

Full control from a single Kubernetes plane

Users can now manage their MongoDB deployment from a single Kubernetes control plane. On self-managed infrastructure – whether on-premises or in the cloud – Kubernetes users can use the MongoDB Enterprise Operator for Kubernetes and MongoDB Ops Manager to automate and manage MongoDB clusters. Developers can use the operator with upstream Kubernetes, or with popular distributions such as Red Hat OpenShift and Pivotal Container Service (PKS).