Desde que o MongoDB adquiriu a WiredTiger e seu mecanismo de armazenamento de banco de dados relacional, especialistas tem especulado sobre quando o MongoDB suportaria transações de documentos múltiplos. Com o recente anúncio, a expectativa é que esta nova funcionalidade esteja disponível neste verão como parte do MongoDB 4.0.
Grigori Melnik of MongoDB afirma que de "80%-90% das aplicações não precisam de transações de múltiplos documentos" (embora essa afirmativa possa ser questionável, já que bancos de dados hierárquicos tendem a ter muitos dados desnormalizados que precisam ser atualizados em vários locais simultaneamente para garantir consistência). E e segundo seu ponto de vista alega que:
Alguns desenvolvedores e DBAs foram condicionados por 40 anos de modelagem de dados relacionais para assumir que transações em múltiplas tabelas/documentos são um requisito para qualquer banco de dados, independentemente do modelo de dados em que eles são construídos. Outros estão preocupados que enquanto transações em múltiplos documentos não são necessárias nas aplicações existentes atualmente, no futuro este recurso pode ser necessário, e com isto, não desejam que seus bancos de dados cresçam excessivamente.
O suporte para transações de múltiplos documentos, um pilar do ACID, começou com o MongoDB 3. Nesta versão o MongoDB ganhou multiversion concurrency control (MVCC), uma técnica para o isolamento de snapshots frequentemente associada aos bancos de dados relacionais PostgreSQL e Oracle. Versões recentes do SQL Server também usam o MVCC para suas tabelas "otimizadas em memória".
O MongoDB 3.2 adicionou suporte ao "read concern". Anteriormente, os clientes recebiam os dados da maneira como era conhecido pelo nó com o qual estavam se comunicando. A opção read concern permitiu que os clientes exigissem que os dados fossem conhecidos pela maioria dos nós. É importante observar que, de acordo com a documentação, "independentemente do nível do read concern, os dados mais recentes em um nó podem não refletir a versão mais recente dos dados no sistema".
O MongoDB 3.6 forneceu então o que foi chamado de "causal consistency". Em versões anteriores do MongoDB, não existia garantias que as operações aconteceriam em uma ordem particular. Era possível, por exemplo, apagar um conjunto de registros e então executar uma consulta que poderia retornar os registros que acabaram de ser apagados. Com o causal consistency, é possível indicar que a operação de leitura depende do resultado da operação de escrita, assegurando assim que a remoção tenha terminado antes de executar a leitura.
Finalmente, o MongoDB 4.0 irá oferecer a possibilidade de executar uma leitura consistente. Que irá retornar somente os dados que são conhecidos no momento que a operação de leitura começar. Como explicado no artigo, A Quick Primer on Isolation Levels and Dirty Reads, versões anteriores do MongoDB poderiam retornar resultados que não eram necessariamente consistentes com qualquer ponto no tempo. Poderia inclusive escapar documentos ou retornar múltiplas versões do mesmo documento em uma simples consulta.
Desenvolvedores que queiram experimentar o novo recurso de transações de múltiplos documentos são encorajados a se inscrever no programa beta do MongoDB 4.0.