Rez Khan on MongoDB, Databases, and Developer Tools

Share Deep Dives is published by Share, an app to help consumers achieve their investing goals with less work and more fun, join the beta here!

Below is a transcript of my interview with Rez Khan, co-founder of Pace and previously a Group Product Manager at MongoDB. We ran out of time, so this is part one of two, where we discuss developer tools. In part two we will discuss product-led growth and how companies are applying it to sales. The transcript has been edited for length and clarity.

---

Kareem: Ok, I’m here with Rez Khan for the first ever Share Deep Dives where we’re going to dive deep into a sector, or a domain, or an industry with an expert. Rez has generously agreed to be our first expert, so Rez thanks for coming on.

Rez: Thank you for having me.

Kareem: My pleasure. Today we’re going to talk about a couple of things. Developer tools, maybe a bit about databases, as well as your new company Pace, which is focused on product-led growth. So we’ll talk about what that is. But why don’t we start off with a bit about your background, and an overview of you.

Rez: Yeah, lovely to be here, thank you for having me. My name’s Rez. I’m from New York. I’m the cofounder of a company called Pace. We started the company around a year back, last summer. We’ve been running it for a year, we have about 10 people now, and like you mentioned, Pace is a sales-enablement tool for product-led growth companies. Which means we help enterprise software companies with a product-led growth motion figure out the best way to layer in sales on top of product-led growth.

And tactically that means figuring out which of their free tier customers are the best customers for them to engage with, and which of their self-serve customers require account management help or customer success help at the right time.

Prior to Pace, I worked at a company called MongoDB. For those who don’t know, MongoDB is a non-relational database company. It’s been public for the past 5 years. We started out as a very popular open source product which was also called MongoDB, and now the company makes most of its money through a SaaS version of that open source product called Atlas.

I was one of the first product managers working on Atlas. I joined in early 2018, right after the IPO, and stayed for almost 4 year. In that 4 years, Atlas as a product increased annual revenue from approximately $10-20mm to $500mm. My team of product managers was responsible for what we call the post-acquisition journey. Which means after we acquire a customer, how do we get them onboarded and using MongoDB as effectively as possible, and growing their usage of MongoDB on the platform.

So I’ve been working with developer tools for a very long time.

Kareem: Awesome. So why don’t we start with a focus on developer tools. We have some developer tools strategies on Share, and I’m sure it would be interesting to a lot of people. So it’s fair to say that you’d consider both MongoDB the database and the Atlas product… are they both developer tools?

Rez: Yeah, exactly. I consider them both as developer tools. But what’s interesting is the monetization of Atlas is a little bit different from how developer tools have been typically monetized before the advent of SaaS. For example, if you look at the OG developer tools like VSCode or any other IDEs, they were typically sold on a license basis in the past. So if you were to buy 25 licenses of that particular product, you pay for 25 times whatever the cost is. And the way you use it is you download it, and you run it on your own machine, and you pay on a yearly basis.

What’s interesting with MongoDB Atlas is that we change for the product based on how much it’s actually used by your application. Which means you’re not buying a database license, which you have normally done, but you’re paying for how much databases resources you’re using. In the case of MongoDB it’s things like how many queries are you running, how many hours of database are you using etc. And that starts to look a lot more like a SaaS product, or a marketplace product, where you’re paying based on how much you’re actually using, rather than an old-school licensing product like Oracle back in the day.

Kareem: Got it. Maybe we can step back a bit. I’ve had some debates with other developers as to what is a developer tool or what are the boundaries of a developer tool. There’s sort of obvious ones like, let’s say Mongo like a database you’re using in the development of your software, or Stripe [which you’re using to add payment processing to your software]. Or like you said an IDE, where you’re using it to write code. But there’s also things where maybe the boundaries get a little fuzzier, like PagerDuty or even Asana. How do you think about this space, and what makes something a developer tool?

Rez: Yeah, that’s a great question. At a high level I think you can bucket things into two big themes. One is, there are tools you use that become part of the application itself, and then there are tools you use that make the developer workflow better. So, a database product for example is part of the application that you as a developer are building, because… you need a database! Tools like AWS Lambda for example, which is a server-less function, or tools like Vercel which is an application deployment platform, they are part of the application in a way. So that’s one bucket. The second bucket would be any tools that help to augment the developer workflow. And what do we mean by developer workflow? There are again a bunch of different buckets there. One developer workflow is: how do you push stuff into production? CI/CD. Another developer workflow is: before you push stuff into production, how do you make sure that things will not break? So the testing workflow. And then, once stuff is in production, how do you make sure that you are quickly able to capture bugs and errors as they come about? So these are all the observability and monitoring tools, like you mentioned PagerDuty. Another big example is Datadog, Splunk etc. Then there’s another workflow which is the core software authoring experience. So, what is the best experience of writing code? This is where all the IDEs come in. So those are two big buckets of products that in my mind encompasses what developer tools means.

Kareem: Ok, that’s great. You mentioned Atlas having this revenue model that was a little different from some of the other products that we think about where you just buy a license. I’m thinking about JetBrains, an IDE. One of the questions that comes up to me is, you mentioned that MongoDB is open source. MongoDB started as a database, and grew into, I guess, much more than just a database. How does MongoDB as a company make money, maybe starting even before Atlas, which you mentioned started small and grew into something bigger. Is the database itself a business, and how does that work?

Rez: Yeah. It’s interesting. MongoDB started out, and still is, an open source product. For those who are not familiar with the world of developer tools, open source means the code of the product is published online for anyone to download, and edit, and use. Which is really great for the whole industry, because it leads to a faster pace of innovation. So MongoDB started as an open source product, which meant the code was published online. The product itself was free, so you could download and run it wherever you want. And you never had to talk to or pay MongoDB anything.

Now, one thing that happens is, if the open source product that you’re using is a core part of the application that you as a developer wrote, inevitably your requirements become more and more stringent. And what I mean by that is, you could use MongoDB to build an application and run the application yourself, and run MongoDB yourself on your own machine. But at some point when your application becomes large enough that you have a lot of users using the application, you’ve gotta think about things like “how do I make sure the database is up” or “how do I make sure the database is optimized”. And at that point, you might come to a stage where you might not have the time, or the skills, or the specialized knowledge to be able to handle that part of your job well. So what businesses who are open source first, what they tend to do is they start selling services. So you can talk to, or use the resources that these companies already have, like talk to experts in the companies and fix optimization problems that might come up, or help you fix bugs or do new use cases that are hard for you to figure out on your own. And MongoDB did that, they sold services. And then at some point, even if you’re using the free open source version, you might require features that only make sense for an enterprise. So stuff like “I need special security features”. In those cases what open source businesses do is they tend to fork, and have two versions of the product. One version of the product is the core open source product, the other version of the product would be something like the core open source product plus a package with these additional security measures. And they would sell licenses against that second version of the product. And that’s what MongoDB did as well.

And then, what’s interesting with a database product is, like I mentioned, databases need to operate very well at high scale, and you need to manage the database being up, and handle upgrades and downgrades and all that stuff. So what MongoDB did is they built a bunch of software products to help you manage the running of MongoDB. And they sold those products as licensed products as well. And at one point, around 2017 (before I was at MongoDB) they realized “were selling all these products to help customers manage MongoDB, and we’re selling these services so that customers can use MongoDB in more effective ways, so what if we just make the whole thing even simpler and just expose the whole experience as an API”. So you don’t have to worry about downloading it, running it in a special server, what the server is, upgrading, downgrading, sharding, scaling, all that stuff is taken care of for you. And that became the Atlas product, and the experience was very nice because as a developer you could just go online to cloud.mongodb.com and say “I want a database with this much capacity” and that database is initialized for you, and we give you an endpoint to push and pull data, and you don’t have to worry about any of the ops stuff underneath the hood.

So what’s interesting is, Atlas isn’t really selling MongoDB. It’s selling the management of MongoDB, and because we’re selling the management of MongoDB, and management requires ongoing maintenance costs, both from an infrastructure perspective and a people perspective, we could start charging for usage. Which is very beautiful because as your company grows, as your application grows, you’ll use more and you’ll pay MongoDB more. So the business model is really awesome. The cloud, SaaS, usage-based business model. So one thing to watch out for when you’re evaluating developer tool companies is whether someone can pull that particular business model off.

Kareem: Is it accurate to say that Atlas is a database as a service?

Rez: It’s a database as a service, yes.

Kareem: Ok, and you mentioned when you started this was still a pretty nascent, or small part of MongoDB, and it grew into a very large part. Is that now the dominant driver of MongoDB’s revenue and has become the flagship or main part of the business?

Rez: Yeah, I think it surpassed the other sides of the business in terms of revenue sometime last year, or maybe this year I don’t really remember. But from a growth perspective - and this is all public information - MongoDB Atlas is growing at 84 or 85% year over year. The other side of the business is not growing as fast. It’s growing healthily but not as fast. So it didn’t take a long time for Atlas to eclipse the revenue from the other side of the company. And it’s fair to say it’s the dominant revenue driver for MongoDB at this point, and that will probably be the case for the next few years at least.

Kareem: Yeah, I didn’t know that. That’s interesting. So, in the case of MongoDB… are they more in competition with, I think of something like RDS [Amazon’s managed database product]. I can get a database hosted by Amazon, or I can get a database hosted by Google. So is that more their competition than something like Postgres [another open source database] or is it both? Is it both the database software vendors and also the services vendors?

Rez: Yeah, so MongoDB’s roots is as a document database. Which means you store data inside MongoDB as a JSON [a type of data format] document as opposed to rows in tables [like in a traditional relational database] and there’s a bunch of developer experience benefits and scaling benefits which come with that. Over time, MongoDB has started offering support for other use cases beyond just reading and writing documents. So one use case that they talk about a lot is search. So if you have a bunch of text fields in MongoDB and you need to search for it quickly, and searching for it means you need to get not just matched expressions, but also rank them in terms of relevancy, you can do that directly from inside MongoDB, as opposed to using another product like Elasticsearch [another database product purpose built for doing search]. Which is a really nice developer experience.

So in the beginning, MongoDB competed with other non-relational, document based databases like DynamoDB [a database offering from Amazon]. As document databases became better and better, they started competing directly with the relational databases because you could build an application that you’d build on Postgres [a popular open source, relational database] on MongoDB and see very similar performance characteristics. So that’s where you start to compete with RDS [Amazon’s managed database offering] or even like Oracle, for example. I think in the next 5-10 years you’ll probably see MongoDB doing, well they’re already doing search, but going to other types of database use cases. So it would start to compete with other services, the hyper-scalers, the big cloud providers.

Kareem: It seems like the developer tools ecosystem… well it’s interesting. On the one hand it feels like it’s very fast moving and things change very quickly.

Rez: Yep

Kareem: On the other hand there are some old stalwarts like MySQL [an open source, relational database created in 1995] that have been around for a long, long time and still seems pretty popular. So my question is, as a developer tool in this ecosystem that is evolving very rapidly, how do companies stay relevant and avoid being disrupted? Is that what you’re talking about when you describe MongoDB laying on these new features, or what else are you thinking about?

Rez: Yeah, let’s talk about the space in general. It’s very fast moving. And I think part of the reason why it’s very fast moving is, your customers if you’re building a developer tool company are other developers who are also builders. And if they recognize an inefficiency, their natural reaction is to go and build tooling around it. So there’s this very nice, virtuous cycle of continuous innovation happening because the makers are also the consumers. Which is really nice, and really unique compared to any other industry. Obviously, that can be a problem for the stalwarts, but for the end user it’s great because you’re continuously seeing new types of products coming in.

So, being on top of newer paradigms, newer ways of building products is something that any good developer tooling company does. When I was at MongoDB we used to obsess over this. We used to obsess over what new YC [an investment fund for early stage tech companies, including developer tools] startups were doing. We used to follow those trends very carefully to make sure that we were not being disrupted without even knowing it.

One of the interesting things is, and this was a conscious decision that we had to think about, software as an industry is actually fairly old now. I think it’s 30 or 40 years old now, probably even older than that. So there is a ridiculous amount of software that has been written over the past few decades that is running on legacy tooling. There’s a lot of stuff running on Oracle or MySQL, and other tools that I’m not mentioning. So one of the things that any developer tooling company thinks through is, when we go after a new customer should we try to get the customers who have a lot of legacy software built and have them modernize that software with my tool, or should we go after new customers. And that’s a very interesting choice, because in some cases you shouldn’t think about… all the software written on legacy tooling and try to convert them to the new way of doing things and make money there. You can probably make a very big business just by going after new applications which are being built. Because one interesting thing about software is, as software is eating the world and everything is becoming software-driven, there are probably more applications built in the last couple of years than in the last 10 years. So if you go after just those new applications, and push your tooling there, you can probably make a lot of money. So there are a bunch of clever optimizations you can do on how you go to market, based on how quickly software as an industry is growing, and how much new software is being written every year.

Kareem: Yeah. That’s really interesting, because I remember when MongoDB came out. NoSQL [another name for a document database] wasn’t new in that I don’t think it had been newly invented, but it was newly popular. And MongoDB really kind of exploded on the scene in a way that, there was a bunch of document databases around and yet it seemed like MongoDB took off or became the most popular one quickly. Do you have an explanation for that success, as to why it might have won, that is maybe applicable to other developer tools as well?

Rez: Yeah, that’s a really good question. There was a lot of luck obviously. It’s not like they had a crystal ball and they knew exactly what they were doing. They did a lot of things right but they probably also got very lucky. Some of the things that happened that I think other tools can learn from… back in 2012, when MongoDB started hitting that hockey stick growth in terms of adoption, they were part of the MEAN and MERN stacks [a group of tools for building software using the JavaScript programming language] and there were a lot of people entering the market to be developers. And when you have someone entering the market to be a developer, they’d usually learn JavaScript and JavaScript frameworks etc. And because MongoDB was a part of the MEAN/MERN stack, if you’re a developer learning JavaScript, you use MongoDB to build an application because it’s part of the stack, and there’s a whole bunch of content about the stack. So that’s when the hockey stick growth started. Lots of new applications were being built on MongoDB, and a bunch of those new applications ended up becoming actually big companies, who were now running MongoDB and could become MongoDB cloud customers.

So one lesson for me here is developers tend to think in terms of a stack. So what are the tools I can use together to build an application. So even if you’re one tool, it’s good to think about what collection you are part of. And this analogy extends to other adjacent industries. For example, I’m in the data industry, and the stack in the data industry is the “modern data stack”, which is a cloud data warehouse, an ETL tool, a reverse ETL tools, and tools like Pace on top of that. So it’s important to think about which stack you can be a part of, and merchandise yourself in that particular way.

Kareem: That makes sense. So I’m trying to think of how developer tools are different from other industries or businesses, and one thing that occurs to me is that, as you mentioned, you have developers adopting this product or tool to build something, but they’re not really trying to buy it, they’re not running a business. So who is the buyer of these tools and maybe how does selling developer tools differ from selling Salesforce or something?

Rez: I think the biggest thing is, for developer tools you need to provide an easy way for your customers to experience the product by themselves. So if you have an open source product, you can download the product yourself and learn it without talking to anyone or any sort of paywall, and if you like it while you’re learning it then you might end up using it in an application. I’ve seen very few developer products that are behind some sort of a paywall or some sort of an activation wall. It’s generally available for free, where free could mean open source or free could mean a free version of the SaaS product, like classic product-led growth stuff.

So step one is, you want to get people to start using it, learning it, liking it, and your go-to market strategy should be around that. So the levers are: what is the free version of my product - open source or a free tier SaaS? What is my education strategy, do I have docs or tutorials or courses? If people have questions, where do they ask those questions and who answers them? How do I build a community around people who are using the product so they can learn from each other? So you focus a lot on those things, and then your goal should be to get your product into product. And what that means is, you have the product either being used as part of a real application, or as part of a real workflow of the development team. And only once you get to that can you start thinking of monetization. So it is more of a long game. It’s very very rare to create a developer tool company and monetize it in 6 months, it takes a couple of years for you to get adoption and some familiarity.

Kareem: Yeah, that was my thought. You have to build something first, and if it’s useful it’s probably pretty hard to build, and then you also have to grow. Which explains why a lot of developer tools do start as just an open source tool and then layer a business on later.

Rez: Exactly.

Kareem: So maybe just a last question, let’s tie this into investing a little bit. Say I’m an investor, and I’m trying to look at startups or maybe public companies, and obviously we’re not giving investment advice here, but how do you think about evaluating the health of developer tool companies beyond the standard stuff. Obviously we can look at revenue and profitability and all the classic business metrics, but if I’m looking at a developer tools company, is there anything I’m looking at that is non-standard to try to evaluate both the current health and maybe the long term defensibility of these companies.

Rez: Yeah, that’s a great question. I think I mentioned a couple of things already, but one very important thing is how sticky the developer tool actually is. If you have an application which is using the developer tool in production, let’s say it’s a database and it’s being used in production, that is as sticky as sticky can be. Because migrating a database is very, very difficult. Or if your tooling is used as part of the CI/CD workflow and you have hooked into the APIs and built a lot of custom workflows around it, that’s super sticky. So if those things are happening for your target product, that’s really really good. One example is GitLab. GitLab is a core part of the user workflow, and it’s so sticky it’s very difficult to move from GitLab to some other tool so as your customers grow, GitLab consumption would also grow, so there’s a natural growth curve for those kind of businesses that you need to be cognizant of. That’s one of the more interesting things I look for.