Q&A With a MongoDB CTO
When it comes to database companies, few have had as good a run as MongoDB over the past year. With an IPO last fall and a cloud business that’s booming, the New York City firm is flying high. This week at the MongoDB World conference, the company’s co-founder and chief technology officer, Eliot Horowitz, sat down with Datanami to talk about how the company got to where it is and where it’s going next.
Datanami: MongoDB‘s customer base has doubled in the past year, and you now have more than 6,600 paying customers. What’s driving that growth?
Eliot Horowitz: From early on, when we first released MongoDB, people thought the document model was awesome. [But] there were lot of features and a lot of maturity on the tools we needed to build before people would be comfortable putting mission critical workloads on it.
A few years ago, we kind of turned the tide and people started to say “Oh, I can put mission-critical workload on it,” and we had big banks put mission-critical workloads on it and then talk about it at MongoDB conferences. It kind of snowballed.
The first version of Oracle that people thought was actually decent was 13 years in, with Oracle 6. We’re 10 years in. Relative to any other database in history, from inception to mission critical workload and people actually being ecstatic about using it as a platform, it’s off the charts.
We’ve got so much more we want to do. Five years ago people thought we’d never get to where we were without transactions. We’ve exceeded what people would have expected without transactions, and now we have transactions, which is going to be another game-changer.
DN: MongoDB had its IPO last fall. How much of an impact has that had on your business?
EH: We haven’t seen the full effect of that yet. We’re just beginning to see the effect us going public in the market. Even three years ago, I remember customer meetings, and customers’ biggest concern was “Hey are you guys going to go out of business in two years? I don’t want to bet my business on a technology that I don’t have confidence in.”
Database choices are long-term choices. Being public, people can see exactly what’s going on. People can see that no, we’re actually quite stable. We’re not going anywhere. And that gives people a lot more confidence to bet their business on MongoDB.
DN: You just shipped MongoDB 4.0, which brings support for multi-document ACID transactions, and you talked in your keynote about supporting sharded multi-document ACID transactions in version 4.2. What will that get your customers that they don’t have now?
EH: The ability to scale out the transactions and the kinds of transactional workloads you can do in sort of an even bigger way.
In 4.0 you’re going to have to choose whether you want transactions or pure scale-out. Now it turns out there are very few workloads that need both. There are very few workloads in MongoDB that need transactions, as evidenced by how many use case there are on MongoDB today. But there are even fewer that need both transactions and scale-out. But sometimes they’re pretty interesting ones when they do, so that will be available.
DN: So you currently only support multi-document ACID transactions on a single node?
EH: No, on a single replica set, which is multiple nodes for high availability and those things. So it’s [support for multi-document ACID transactions] in a single replica set.
DN: Can you elaborate on replica sets? How are they different than nodes?
EH: People tend to think of nodes as a single machine, whereas a replica set is three machines or five machines — it can be as many you want, but at least three, so that if one fails, all the nodes have the same data…and another one takes over. So as long as two out of the three, or three out of five, or four out of the seven are up, then your cluster is up.
DN: So if a large bank wanted to run its worldwide transaction system on MongoDB, they would be unable to do that until they have support for multi-document sharded ACID transactions?
EH: No, that would actually work fine now. Humans don’t generate that many transactions…The intersection of where you need transactions and really high scale-out isn’t actually that common. It exists, but it’s not that common.
The weird things about transactions in MongoDB is, because of the data model, you typically don’t need transactions. There are a lot of very big applications that are mission-critical that deal with trading and money moving around, big banks that are scaled massively on MongoDB without transactions. Just because it’s a banking application and they’re dealing with real-world transactions, that doesn’t actually equate to database transaction, especially in MongoDB. The whole point of the MongoDB data model is you can put lots of things together.
[MongoDB customer JPMorgan Chase’s] equity-swap business deals with trades. The beauty of the MongoDB document model is they put every attribute about that trade in the document. And they love that for a number of reasons. One MongoDB document equals one real-world transaction, so you don’t need transactions in MongoDB to support that. So when a regulator comes by and says “Hey I want to understand this trade and if was OK or not,” it’s literally one document they have to go look at and everything they need about that trade is in one place.
DN: Maybe we need a better term or concept than ACID transactions to represent this capability?
EH: We really do. We’ve had this debate internally. So in MongoDB, you’ve got one document. You can modify lots of different parts of that document in one operation. You’ve always been able to do that without multi-document ACID transactions.
A few years ago, we said, Look, you don’t need multi-document transactions because you can do this thing where you can update this field and this field and this field — this entire array of fields — in one operation. We said, that’s kind of like an ACID transaction. And the database community said “No that’s not ACID. That’s not multi-row, it’s not multi-document. You can’t call yourself [ACID compliant].”
We didn’t want to get into this esoteric sematic debate about what ACID transactions actually meant, even though we probably were right. And so in some ways we said, we don’t want that fight, we don’t need that fight. We have ACID transactions now. We’ve done the work. People wanted it anyway, we’ve checked all the boxes. We gave the people what they want.
DN: So we know that sharded multi-document ACID transactions are coming in MongoDB 4.2. What other cool stuff are you working on?
EH: Oh, so much cool stuff. Without saying things I’m not supposed to say, the key thing I’m working on are features of the database and features in the pieces around the database.
So there are three major product categories. We’ve got the database, we’ve got Atlas and we’ve got Stitch. We’re constantly looking at features to add to those three platforms to make it easier and easier to build great applications.
If you think about Stitch, there are so many little pieces of applications that are a pain. In the core database, I would say the big focus for us is on query, analytics, and making those things as fast as possible. We we see a huge convergence of people not wanting to manage separate operational and analytical database. They want a unified system. So making MongoDB better and better at analytics and those things is a big focus.
DN: What about languages? Are there any new ones you’re looking to support?
EH: We support pretty much all of them. We’re working on Swift right now. The mobile version [of the database] is coming out now. We’re doing a server-side version of Swift. We’re always looking at new languages. This is where open source is pretty cool because typically when a new language comes out, the community goes and writes a driver and then … we work with the community to figure out how to make it officially supported.
Swift is the newest one. Swift and Go are the two most interesting ones right now. We actually do support Go. We’re releasing a new version of a MongoDB official Go driver. It’s actually a language we use very heavily internally.
DN: Another feature of MongoDB 4.0 is MongoDB Mobile, which is now in beta. How will MongoDB Mobile change how developers write applications?
EH: In some ways, not very much. A lot of what we’ve done over the last few years is make MongDB run anywhere. So for example, a lot of the work we did to make MongoDB Mobile was the same work we did a couple of years ago to make it work on ARM and mainframes.
Today, whether you’re using MongoDB on the backend or not, almost every API that a mobile application is using is JSON over REST. It’s a huge percentage, whether or not they’re using MongoDB on the backend. Hopefully they’re going to use more MongoDB on the backend, but regardless of what they’re using, the API is still JSON. So now they can take JSON off the API, whatever they’re using as a backend, and put it in MongoDB. There’s no other better way to query JSON, by far, than the MongoDB Query Language. So they can store it, query it, work with it, do analytics on it in its native JSON form.
It’s just going to be a huge productivity boost to people writing mobile applications…. It’s going to make the applications faster. It’s going to get features out faster and make the applications themselves faster. Probably use less battery too.
DN: What is MongoDB doing with machine learning? Will MongoDB Mobile accelerate that work?
EH: We get asked that a lot and, frankly, all the machine learning technologies and platforms integrate really well with Mongo already. We have a ton of customers and users who store training sets in MongoDB, use any of the machine learning toolkits to do the processing, and then store the models back in MongoDB afterwards.
It works quiet well today and the [machine learning] platforms tend to work quite well with MongoDB so we haven’t done a ton to make it better….We’ve got a great Spark connector so it works pretty well out of the box
DN: There are so many great tools available to developers today. What can MongoDB do to make things even better for them?
EH: It’s a good time to be a developer. I think Stitch is going to make developers more productive. [But] it can always be better. Don’t worry — we’ve got plenty to do. We’ll be here next year with just as many new cool things — hopefully more. That’s the goal every year.
DN: Thanks for your time, Eliot.
Related Items:
MongoDB Fleshes Out Mobile and Cloud Strategies
A MongoDB Secret Weapon: Aggregation Pipeline