Yesterday I did a fireside chat at our portfolio company Shippo and someone asked the question how a company can continue to be successful and grow over a long period of time. My answer was: continue to innovate. A company that wonderfully represents that spirit is MongoDB. Eliot Horowitz, the co-founder and CTO of MongoDB, just announced in a blog post that MongoDB 4.0 will support multi-document transactions.

You should go read the post as it is great, including the epic title “MongoDB Drops ACID” (which I will explain later), but here is the quote that really stood out to me (emphases in bold are mine):

The imminent arrival of transactions is the culmination of a multi-year engineering effort, beginning over 3 years ago with the integration of the WiredTiger storage engine. We’ve laid the groundwork in almost every part of the server – from the storage layer itself, to the replication consensus protocol, to the sharding architecture.

Yes. MongoDB started the work for transactions 3 years ago. And they had to touch every part of the product to make it work. That’s what it means to be a company that continues to innovate.

Continued innovation requires real commitment, but it is also extremely powerful. Many companies simply don’t do it and so it is a crucial source of competitive advantage. Making continued innovation part of the DNA of a company also means you can start out with a simple product, one that others dismiss as a “toy” and keep making it better.

So what exactly are ACID multi-document transactions and why do they matter? ACID is an acronym for Atomicity, Consistency, Isolation, Durability. These are all desirable properties of a transaction, where a multi-document transaction is a change to the data contained in multiple different documents. The canonical example in computer science here is transferring money from one bank account to another. In the database each account is represented by a document that contains information such as the account number, the account type and the balance on the account. 

Transferring money from account A to account B thus requires decrementing the balance field in document A and incrementing it in document B (hence multi-document). We would like such a transaction to be:

Atomic - meaning either both changes occur or no change
Consistent - no one else accessing the database can see a state in which say the balance document A has been decremented but the balance in document B is still unchanged
Isolated - if you are running many multi-document transactions at once they do not interfere with each other
Durable - once a transaction is done, it is really recorded in the database even if say the power to one or more components of the database fails

As you might guess just from reading it, this is hard to achieve. Traditional relational databases, however, have had ACID transactions for a long time. They really come in hand for writing certain types of systems, such as say an accounting application. Well, as of the 4.0 release this summer, MongoDB will have them as well.

That’s great news not just for people writing new applications, but also for those who want to lift existing workloads from older databases to MongoDB. To the extent that those applications required transactions they can now be ported much more easily. That in turn means that customers can more easily standardize on MongoDB as their database of choice.

Congratulations to the entire team at MongoDB on this major accomplishment and their ongoing dedication to continued innovation! 

Yesterday I did a fireside chat at our portfolio company Shippo and someone asked the question how a company can continue to be successful and grow over a long period of time. My answer was: continue to innovate. A company that wonderfully represents that spirit is MongoDB. Eliot Horowitz, the co-founder and CTO of MongoDB, just announced in a blog post that MongoDB 4.0 will support multi-document transactions.

You should go read the post as it is great, including the epic title “MongoDB Drops ACID” (which I will explain later), but here is the quote that really stood out to me (emphases in bold are mine):

The imminent arrival of transactions is the culmination of a multi-year engineering effort, beginning over 3 years ago with the integration of the WiredTiger storage engine. We’ve laid the groundwork in almost every part of the server – from the storage layer itself, to the replication consensus protocol, to the sharding architecture.

Yes. MongoDB started the work for transactions 3 years ago. And they had to touch every part of the product to make it work. That’s what it means to be a company that continues to innovate.

Continued innovation requires real commitment, but it is also extremely powerful. Many companies simply don’t do it and so it is a crucial source of competitive advantage. Making continued innovation part of the DNA of a company also means you can start out with a simple product, one that others dismiss as a “toy” and keep making it better.

So what exactly are ACID multi-document transactions and why do they matter? ACID is an acronym for Atomicity, Consistency, Isolation, Durability. These are all desirable properties of a transaction, where a multi-document transaction is a change to the data contained in multiple different documents. The canonical example in computer science here is transferring money from one bank account to another. In the database each account is represented by a document that contains information such as the account number, the account type and the balance on the account. 

Transferring money from account A to account B thus requires decrementing the balance field in document A and incrementing it in document B (hence multi-document). We would like such a transaction to be:

Atomic - meaning either both changes occur or no change
Consistent - no one else accessing the database can see a state in which say the balance document A has been decremented but the balance in document B is still unchanged
Isolated - if you are running many multi-document transactions at once they do not interfere with each other
Durable - once a transaction is done, it is really recorded in the database even if say the power to one or more components of the database fails

As you might guess just from reading it, this is hard to achieve. Traditional relational databases, however, have had ACID transactions for a long time. They really come in hand for writing certain types of systems, such as say an accounting application. Well, as of the 4.0 release this summer, MongoDB will have them as well.

That’s great news not just for people writing new applications, but also for those who want to lift existing workloads from older databases to MongoDB. To the extent that those applications required transactions they can now be ported much more easily. That in turn means that customers can more easily standardize on MongoDB as their database of choice.

Congratulations to the entire team at MongoDB on this major accomplishment and their ongoing dedication to continued innovation!