Transcript
Akshat Vig: While preparing this keynote, I realized that Andrew and I, we both have spent almost a life working on databases. To my friends, and maybe to some of you as well, it might feel like a plot of a very boring movie, but I assure you, it's not that. There is a lot of fun. There is a lot of drama. There has been outages. Overall, it has also given a lot of character growth. How many of you came here thinking that, yes, I'm going to learn about databases today in the keynote? I'm going to disappoint you. This talk is not about the database. This talk is about the movement behind the database. That movement has two heroes, obviously not me and him, but it's the document model and the community that took the document model, which was the need identified at the time MongoDB was founded, and how that community helped us get to the place where it has become like the default for a lot of mission-critical workloads.
Andrew Davidson: It really is an honor and a privilege to be with QCon, a community that is focused on community and software engineering, and that's very much the spirit of MongoDB as well. I wanted to share my own personal story of even landing at MongoDB back in the earlier stages of my career, because I'm from the San Francisco Bay Area, grew up here. I never really thought that I would end up in a New York-based company. MongoDB is a New York-based company. I was working for a big corp here. I eventually decided it's time for me to move to the next thing. I'd spent a week in Black Rock City. I spent a year living in a developing country in South Asia. I went back to the basics. I was retooling, trying to look at things in a more fundamental light.
As all Californians of that era, I believed if I was moving to New York, I was going to have to wear a suit, so I literally had a suit tailored there. I showed up for my first job interview in New York wearing the suit, and the people were like, "I'm sorry to tell you this, but in tech in New York, we don't wear suits". I was a little humiliated by that moment, but unbelievably for me personally, I was able to find a real tech company, a deep tech company in New York. That was rare, frankly, even still, I would argue, pros and cons to that. The great thing about New York is that the customers are all right there outside your doorstep.
Building the MongoDB Way
I remember when I was interviewing with MongoDB, I said the two things I'm looking for in terms of changing what I could do in my career from what I've done before is I want to feel like I can have an impact on the business, and more importantly, I want to feel I can really interface with and directly influence and experience feedback from customers. I didn't want to be hidden away. I remember the very first day when I started at MongoDB, it was literally an all-hands company offsite, and it was the day after, the Monday morning after the San Francisco 49ers had lost the Super Bowl against the Ravens.
I was sad coming into this Monday morning situation, and basically, I spent the entire day watching lightning talks about customers and about deep database internals. I saw that the customer-oriented people and the software engineers building the platform, there was a complete gradation between them. They were working together. I felt like this is the fantasy that technologists look for. Maybe we imagine the early days of a Bell Labs where everyone's coming together and collaborating on problems. People were buzzing in and out, going on customer calls, escalations, no doubt, some of them. It just felt like we were hooked into the back end of the global economy. This is even before really SaaS. For me, that's when I was really hooked. I wanted to share that story about how I personally first was introduced to this idea that our founders had of building on the document data model. This idea that they wanted to carry forward, and to this day, continues to grow.
We want to introduce to you today what we're going to call building the MongoDB way. It starts with finding some severe frustration or pain or some issue that because of change, because of becoming a frog coming to boil, you must take action to break out of. It has to do with learning in public, being vulnerable, making huge mistakes inevitably because you have to move fast, you have to get battle tested, you have to be testing in production to some extent. That's just the reality. You can't wait decades to bring a database to life. Slowly building up trust, taking advantage of fashion and hype cycles to an extent, but never letting them define you. Realizing that nobody understands what you are other than yourself. Everyone's going to try and define you. You have to know what you're trying to do, especially if you're trying to do something long term, like disrupt the transactional database segment. This is a 50-year domain. How to build a business around that.
Use Frustration to Bend Reality
The first question is, how do you decide to take action at all? That decision you don't necessarily know you're making, the easy thing to do is to just build the way everybody else is. In the early 2000s, that was a relational database. Everyone was doing that. You're not going to get fired for making that approach. To come in and decide, I want to be a bit radical. I want to disrupt something that is so foundational, that underpins the bottom of the software stack, you have to be a little bit nutty. I think of that TED talk of the first follower makes the lone nut a leader. You have to be comfortable going out there, and it's going to hurt. You have to be excited by the idea that the world is changing, and you have an opportunity to bend the firmament of the world, to change the outcome longer term.
If that's the way you think, if you want to feel like you're having an impact, then the ideas that you're working on can ripple around the world. I have a physics background, I always personally think about the moment after the Big Bang. I think about those little perturbations, they call them quantum fluctuations, that later led, after the inflationary epoch, to the galaxy clusters that define our universe today. I think if you could get excited by the idea of trying to make changes happen in that early perturbation mode, then you can have this huge impact long term. The only way to do that is to get involved when there's a real need. Things have to be changing.
Let's talk about some great examples in history. Think about Unix. The backdrop was a world where computing, computing dated back to government use cases. Think about weapon simulations, think about census, think about electronic medical records born in an era of eugenics and empire, dehumanizing compute, focused on reporting on people. In that era where most people couldn't even access a mainframe, and if they did it was on a punch card, to have the rise of minicomputers and the rise of a new operating system that had a philosophy, that had a way of building about small, bite-sized components, laying the groundwork for microservices, clear inputs and outputs, portability. Unix was a completely democratizing move in the history of computing.
An order of magnitude more, people were building software and interacting with software. Even though Unix initially was very much about challenging the powers of the moment, over time, inevitably, Unix became a bit captured by the hyperscalers of that era. It laid this incredible foundation for the open-source movement to blossom. Linus and others coming in and saying there's an entirely different way to build. Yet another order of magnitude more software developers are going to be able to learn, interface, and build on top of with this way of building. Of course, when you flash forward to today, open source has completely taken over the world. In some ways, you could say it's the best of time for open source. In some ways, it's more complex. We're going to get into that a bit later.
Fundamentally, you have to ask yourself, do I have something that needs to be changed so badly that it's going to be irreversible when someone gets a taste of it? It needs to be not just a push, not just a pull, but both. There needs to be something so fundamentally different about the old world. You're not going to go backwards to the mainframe. You're not going to go backwards from open source. It needs to be so fundamental that it pulls you in. To find something like that, typically, you need the world to be changing all around you.
Akshat Vig: Another thing about these irreversible changes is that in that moment, you have to take a contrarian stance. Because if you take that contrarian stance long enough, it becomes reality, and the other side is really worth it. That's what happened in the case of the document model as well.
Andrew Davidson: That's right. People will stand out there and celebrate that they're experiencing this new thing. It will also be incredibly controversial. There's going to be so many people who will feel the exact opposite. That's just the nature of anything that is a fundamental, permanent change. That's what can become demoralizing. Let's talk about the origin story more specifically. Let's talk about this era, 2008. The founders of MongoDB had previously done a company called DoubleClick.
If you're in adtech, you know them. It was eventually part of Google's empire. At DoubleClick, they had seen true web-scale of that era. They had recognized that relational databases were not a good fit for that model. Really, when they started MongoDB, their goal was to do something very different. They actually wanted to build a next generation Platform as a Service. They were focused on democratizing modern application development, and bringing, again, that next order of magnitude. What's interesting is, when they started looking more closely at building a Platform as a Service, they realized that no matter how sophisticated the upstack componentry was, they kept running into the challenges at the database layer. It was like a wall they ran into. Why is that? The relational database dates back to really the 1970s, in which the key cost bottleneck in computing was the cost of storage.
Over time, the key cost bottleneck, you could argue, really became developers' minds. There's other fundamental reasons why the relational database was suboptimal for someone trying to build a Platform as a Service, and that's that the relational database was really not built to enable software as we think about it today. It wasn't really built to enable access patterns that were the shape of software. It was more built to enable arbitrary queries for business users. This meant that it fundamentally had to be vertically scaled. You had to keep everything in essentially the same box. The creators of MongoDB knew this, and they thought, so if we're going to build a next-gen Platform as a Service, really, we have to build a next-gen database. They eventually abandoned the upstack componentry, leaving that to open and composable open source, and went all in on the database, even though that was going to be a brutal slog.
Let's talk about the alternatives in that era. You could roll your own sharding, and obviously so many big companies have done that, Meta with MySQL, Uber as well. The downside of that is you start treating a great relational database essentially as a key-value store. You give up a lot of the benefits. You've created a lot of complexity to manage. You could, of course, cache, layering in a cache, that's always a valid strategy. That basically means you're scaling components of your workload. You're not scaling durable writes, for example. This is just not the be-all, end-all, certainly not for scale. Maybe most importantly, in an era in which we rolled out new versions of software every year, it wasn't a big deal that the schema migrations required downtime.
In an era in which everyone could tell that we were moving towards faster and faster, continuous development, continuous releasing, it was going to be more and more painful to contemplate downtime for migrations. Of course, in this era, we saw Amazon release DynamoDB, we saw Google do Bigtable. Both of those went with essentially a key-value type model, limited secondary indexes, limited querying. That also felt too limiting for the founders of MongoDB.
I wanted to talk about someone who I'm pretty passionate about, named Buckminster Fuller. If you were of the '60s generation, you would no doubt have heard of him. He was one of the most popular futurists of that era. I'm sure many of you have heard of him. What's interesting about Buckminster Fuller is he was famous for many things, but he was most famous for the geodesic dome. The geodesic dome became a fundamental part of so many of the forms in architecture we just take for granted today, theaters, stadiums, airports, they're all around us. What's interesting about Buckminster, and I read his biography, is when he was a kid, he was effectively blind until later in his childhood. He grew up on the coast of Maine.
Basically, his family didn't understand this, and so he was engaging with the world, seeing fuzzy lights, but had a very tactile way of engaging with the organic world around him in this very natural place, the coast of Maine. Once he eventually was prescribed those incredibly thick glasses that he's famous for, he could see. I bring this up because he was not fundamentally biased by what came before, he could see a world that could be built differently. He could literally think outside the box. When you imagine what that enables for an architect, and combine that with what was there before, great things can happen.
In a world in which the relational database tabular model was running into trickiness around schema rigidity, trickiness around downtime, trickiness around both prototyping and evolving, and trickiness around scale, MongoDB's Buckminster Fuller moment, or vision, was absolutely the document data model. Because the document data model flipped the entire idea of software on its head. Application developers are now responsible for the schema, but the data is stored the way it's accessed, so it's fundamentally more scalable. If we had just started there and done only that, I think there'd be a big problem.
I think back to my time in the developing world, and I always find that when you go to a developing city, it's incredible how, in some sense, you're getting to see maybe what the city you live in now was like 100 years ago. It's really inspiring to see the energy, the vitality, building the future. What's also interesting is, of course, people don't need to build the exact same way we might have built 100 years ago. They can skip over things.
For example, they're not going to build landlines today. They're going to go straight to mobile networks. In other cases, I've seen developing cities that skipped fundamentals, like sidewalks. Something that is so fundamentally humanizing, something that we take for granted every day in our lives, but that, if you think about it, doesn't have to be there, and, in fact, sometimes isn't there. It really makes you think. If you're tossing out a lot of assumptions and starting from scratch, you have to ask yourself, is this like landlines? I can skip over it? Or is this like sidewalks? It needs to be there.
Akshat Vig: One thing about these decisions is that sometimes they are like one-way-door decisions, so you have to be really cautious about what you are picking. For example, the query surface that you get exposed when you start supporting joins in a database, that just explodes quite a lot. These decisions about choosing to implement what you want and what not to want is important one-way-door or two-way-door decisions that you have to think.
Andrew Davidson: The ultimate sidewalk preserve for MongoDB on the document model was strongly consistent secondary indexes and expressive queries. Without those, it would have just been fundamentally untenable to express a wide variety of software application use cases. Really, again, going back to the fundamentals here, the world has to be changing. Let's be honest. In the early 2000s, we had larger-scale workloads due to the internet. We had the rise of early cloud, of course. We had the rise of mobile. We had billions of users now for the first time. We had expectations from users on mobile to have geospatial capabilities. So many things were changing. We had frontend developers starting to build applications with server-side JavaScript. There was a lot of frustration and opportunity around all that dynamic change, just like there's so much opportunity around dynamic change in our industry today.
Learn in Public, Build with Developers
MongoDB launched in 2009. After the launch, on the forums and everywhere else, you could feel that you were in the fast-moving water. You could feel that it was really delivering something. Of course, we said it wasn't perfect. It was far from perfect. It had severe problems, locking issues, suboptimal defaults from a security perspective, suboptimal defaults from a durability perspective. These are the fundamentals of the database onion. We weren't there yet, but we were able to get out there instead of spending decades in a clean room. I think the fundamental reality is you have to do that. You have to get out there, otherwise you just don't know if you're solving problems. When you started seeing the feedback on the forums, you knew, ok, this is starting to resonate. This is starting to make sense.
In particular, with the rise of mobile, you could see people building incredible new applications. I think about, personally, Foursquare. I was working at Google Maps at the time. We would think about how incredible it was that Foursquare had better location intelligence by crowdsourcing ground truth to the community of users, while Google tried to do that with a team of operators internally. Tinder, an incredible disruptor in introducing what dating could be in the future. I literally met my wife on Tinder. For me, this was so personal. We could have gone all in and been the geospatial database, but we recognized we always had the long-term orientation that we had to do something that was about fundamentally 50-year secular shift, new way of building transactionally. That's how we did it.
At the Startup Crawls and all the events, you could feel the energy starting to bloom. We were even at QCon London 2012, which is funny when you look at the title of this talk. At the time, everyone broad stroke, big data, Hadoop, Mongo, it's all kind of the same stuff, even though these were so fundamentally different. It's just, again, a reminder that it's so hard to even define yourself. People are so keen to put you in a bizarre box. In San Francisco, we had 400 people at the Palace of Fine Arts. It was just incredible, the enthusiasm, the community building. We had our open-source drivers being created in every language. It was a beautiful moment.
Then, of course, we had this meme that many of you have probably seen. Maybe, I wouldn't be surprised if some of you thought of the meme when you saw us here today, this idea of MongoDB being web-scale. It was a gut punch moment for us. It still is. If I'm ever reading a forum post about MongoDB, someone's always coming in with the MongoDB is web-scale comment. What's interesting about this meme and this moment is it wasn't really just making fun of MongoDB, the technology. It was making fun, to some extent, of this massive order of magnitude more developers that were coming about, people who might have come from bootcamps, people who were more frontend oriented starting to build on the backend. It was incredibly demotivating when you see these types of things.
It goes back to that point Akshat was making of the controversy of trying to disrupt such a fundamental layer. Incredibly demotivating. It's a gut punch. How do you wake up the next morning and want to keep working on the platform that you're doing? How do you do that? The answer is you have to focus on your customers. Not just the person who's going to the next level of scale, but the person who's using you for the first time. If you don't focus there, you just can't keep going.
Akshat Vig: It's funny, the meme, how it got added to the keynote was I was talking to a friend that I'm with Andrew giving a talk, and he's like, are you going to talk about the meme? I didn't know about the meme, so I was maybe too young at that point.
Let's zoom into focus. There is one very interesting thing about focus, that focus brings an unfair advantage. It's not really motivational, but it's actually mechanical. Because when you have focus, you take bets on just one thing, and that reduces the surface area for the team about all the things that you have to worry about. With that unfair advantage, you start to make magical things happen.
At that point, for MongoDB, it was getting adoption of the document model. The focus was, let's figure out how this document model, which already started to get some validation from the community, how do we use this and make sure all the developers who are using the product become successful? Because with that adoption, you start to get scale. Scale is important. Because if you do not get scale, you start feeling demotivated. When you get it, you start to enjoy. You all know that feeling that whatever I've built is working. It's having an impact in the world. It also has teaching moments. Teaching moments like, you get pulled into an outage that happened at 2 a.m. for a customer, and you start looking at logs and ask the question, who wrote this code? What was that person thinking when this code was written? You realize it was actually you who wrote this code.
The scale does not break your system. It actually just amplifies or it actually just brings the truth in front of everyone. Because if you are just building without giving your product to the users, you'll realize that most of the problems you are not able to identify easily. Also, it is not just the system, scale is impartial. It amplifies the truth. It amplifies all the fragile parts in your system. Not just your system, but also the processes that exist in your company, the culture that exists in your company.
Let's look at system challenges, for example. The early release of MongoDB was launched with certain defaults, like connection limits. There were 20,000 connections, and at that time, all that made sense. Because the scale that the database was seeing was enough with that connection limit. Similarly, there were defaults chosen for the right concern. There were defaults chosen for concurrency limits. There were defaults chosen for garbage collection. You'll read a lot of blog posts about all the issues that were happening because of these limits. Now it's obvious that the community who was championing the document model, running into these challenges was frustrating for them.
At that point, all of that made sense. Because as I said, the focus was to get adoption of the document model. You might feel that, for a database, not doing all these things doesn't make sense. To get adoption, sometimes you have to do things that don't scale so that you can identify what is not scaling, and then you actually iterate really fast. There are two points I'm trying to make here, one is, there's no compression algorithm for experience. Whatever edge cases you can think of, there are still more that you need to learn.
The best way to learn is to get that product in the hands of customers. Especially for a database, if you want to make it perfect, it will almost take 10 to 15 years to solve all the challenges that you can think of if you are just working in isolation. Second part is, as soon as you discover these problems, you have to iterate fast, so that whatever challenges that the community is facing, because they are taking this product to different parts of the world in their companies, you iterate fast and help them to become successful.
Now you might be wondering, like, this seems easier said than done, because it's like you are a new database company, or you're trying to move a new revolution, how do you get adoption? Because it seems like a chicken and egg problem. There is no right answer for this. In the case of MongoDB, what worked was, one, it started the open-source model, so every change was happening in public, everyone could see that. The community was taking part in championing, in helping figure out where the challenges are. Second is that there was this wave, the hype, which MongoDB chose to ride, which was the geospatial indexes that Andrew pointed out. All of that got the database adopted in Foursquare, the Tinders of the world.
Andrew Davidson: It wasn't just there, it was also in payments. Interestingly, Stripe, Coinbase as well. What is maybe more surprising, that just shows how much of a pent-up demand there was for something new, is even in this era, this moment in time, in which you had something that was frankly immature, you had people in banks, you had government also building various applications on it. In banks you had quant workbenches. You had systematically critical swaps products built in household name banks in this era. It's shocking in a sense, they have great governance, they knew what they were doing. It just showed they felt they had no other choice in that moment in time.
Akshat Vig: Then, as you see that these developers are using your product, you start seeing problems, like vertical scaling was also a challenge that we ran into. We had to just figure out a way to get out of that revolution, or get out of the way to enable that revolution. Which means we iterated fast, launched horizontal scaling, and helped the community to become successful. The best part was that all these changes were not just happening in an isolated codebase which was behind the wall, it was made public. Stripe talks about how they are using the community version of MongoDB, and similarly how Atlas was enabling the customers. The lessons that were learned through the scale were getting adopted everywhere. Learning in public, building with developers.
Earn Trust with Every Release
What about the process that I talked about? Scale also changes the shape of ownership. When you are a small team, a single developer, you know the whole codebase. You know what to fix where. If there is an outage, you can go on a call with a customer, identify what problem they're running into, and fix that, deploy it, and send a message to the team that we're done. That won't work as you get to a phase where you have a lot of customers who are using your product. You have millions of databases that you're running. You have millions of TPS that's been running on a day-to-day basis.
At that point, you have to start getting into principle delegation, which would be something about not just thinking about solving that problem at hand, but figuring out how you can solve that problem without being there. You start defining invariants. These invariants are something like truth. These stay true whatever happens. These invariants you put in your codebase so that you don't have to now keep verifying whether the things are working through tests. You put these as asserts in the code.
Then, not just that, you don't stop there. You start defining your goals, your SLOs, so that every team, rather than micromanaging every team, you give them a clear goal that for a database, security, durability, availability, and performance, these are important things. If you're adding a new feature, don't compromise on these. If you are doing any improvement in the stack, make sure that none of this gets impacted.
Patience Outperforms Hype
Just talking about that, or just putting them on a piece of paper on a wall, also does not work. How do you make sure this actually gets adopted everywhere? That's where Ops excellence culture comes in, where you institutionalize a process where the team is learning, the team is laser-focused on all the invariants that you defined, or all the goals that you defined, and you review them on a weekly basis. What are the challenges that happen for a specific customer? Whatever you're doing, now you start doing it in a more structured manner, because it's not just about a hero in the company or in the team, it's about making sure everyone is getting that environment where they all can succeed. You zoom into those problems. You build mechanisms to detect the same problem happening again, to prevent that problem from happening again. If it happens, you build mechanisms to recover quickly. You define goals like, any node that goes down has to come back within five minutes, and if it does not, you do a post-mortem, figure out why that is happening, because your goal is to not lose that opportunity in learning whatever happened.
Then this becomes like an automated flywheel. The overall Ops excellence goes from being reactive to cultural excellence. You'll be surprised, a lot of teams, a lot of companies stay in the stage one, which I have here, which is reactive, for longer than they're comfortably able to admit, because other things become important. The real goal here is you don't want to stay in that reactive state. You start thinking about how to get to that proactive state. You're working really hard to get to that proactive state so that identifying these problems and solving these problems become cheaper and cheaper so that you can innovate.
Another thing about scale is it actually forces specialization. As I was saying, when you are small scale, you think about, I want to just figure out everything on my own. I'll go ahead and maybe build a specific feature like transactions or query plan. These are core fundamental parts of the database that you're learning every day. It also means there are things that you can't really do, because if you have to build, for example, a storage engine from scratch, it's another 10-year project, and that's where you start taking leaps forward.
Andrew Davidson: Ops excellence, I just wanted to underpin something. You can never develop that Ops excellence at this level of scale with purely shrink-wrapped software because you're just not close to the customer's workload. You're not close enough. Especially now, the race to SaaS adjacent to open source is critical. We'll talk about that more. Indeed, in the specialization race, if you're building an at-scale software company, you want to ask yourself, can I jump into the future by bringing in expert talent, maybe expert pre-existing IP? We did this in three seminal ways at MongoDB, and I just want to emphasize, if you start feeling like you're in that fast-moving water, you should be thinking the same way. Akshat mentioned it, the WiredTiger storage engine. This was 2014. This was the team that had done Berkeley DB previously.
They had created a storage engine around lock-free algorithms. It was optimized for concurrency. This is what got MongoDB out of this pit of despair around the database-level locking that would then slightly improve to collection-level locking. This gave us true document-level concurrency. Queryable encryption is a name we have for a capability, but this was actually brought in through some academics from Brown University that were the leaders in a field called structured encryption. If people are aware of this, basically this allows expressive queries on data that's truly encrypted in use.
In-memory, you have ciphertext, and you can actually do queries on top of it. It's pretty mind-blowing stuff. We turned that team into our cryptography research group, and that happened in 2021. We had been in market for some time with vector search capabilities. This is built on top of Lucene, a great open-source part of our stack. We started developing conviction that it wasn't going to be enough to have great HNSW indexes. You're going to want to actually be in control of the embeddings models, the re-ranking models. These are going to be things you want to be able to influence based on the shape of the data itself, rather than expecting our customers to figure all that out. We brought in the team of world-class researchers from Voyage AI. We would never have been able, with database DNA, to build this type of DNA, to be able to build best-in-class models. It was just not going to happen internally. Jumping into the future through mergers and acquisitions is a strategy you should always think about.
Monetize Convenience not Control
Let's go back to open-source. There was this fundamental question of, could we build a sustainable business? It feels like we're achieving this mission of the document model. It feels like developers are able to build in a more natural way. It feels like we can express software that's more human, software that's about information entropy, as opposed to top-down ontology. How do we build a business around this? We were very lucky that when we launched, cloud was still very new. The hyperscalers at that time hadn't developed the playbook yet for turning that open-source shrink-wrapped software into a service. That was going to come later. In fact, we had this thriving ecosystem around us. Idiomatic drivers that were high leverage in each language. We would hire the people who created many of those drivers.
They became part of our company in many cases. They were our chief evangelists in the developer communities. This is what allowed us to bring that Platform as a Service vision to life in an open manner. It wasn't about doing it all. It was about fitting perfectly, if you're in the Java community, into the Spring Boot ecosystem, perfectly into the Node ecosystem, and doing it for all the ecosystems, .NET. This was extremely compelling for us. We have to maintain this mindset even to this day. I think of it as like an Eye of Sauron obsession. You have to know all the things happening in the community. In this moment in time, where everything's about agentic AI, retrieval and memory integrations into the popular stacks like LangChain, LlamaIndex, Semantic Kernel, Spring AI, Maestro, this is where we have to spend time. Obsessively asking, has someone incubated this yet in the community? If not, let's make sure it's happening.
It's very difficult, unfortunately, to monetize open source directly. The reality is, the business model for open source, at this moment in time anyway, early 2000s was a bit different. We know that there's been some great open-source companies, but they ended up being eaten by the hyperscalers of an earlier era. Today, you monetize by building a cloud service. You do that by monetizing convenience. You give people an effortless experience, an unparalleled experience that makes it easy to get started and to scale, which is incredibly difficult. Akshat mentioned Ops excellence. There are no shortcuts here. This is going to take another decade in the case of a database industry.
In many industries, it's going to take you years to really be at mission-critical sophistication and readiness. It was the model that we were able to take because the cloud providers hadn't yet figured out and we got there first. I bring this up because if you're doing this today, it's all speeding up. You have to be building an as-a-service offering earlier in your journey. That's spreading you thin. It's hard to do both. It is hard to have the open source and the as-a-service.
I want to talk briefly about licenses. It's important to understand, maybe many of you are passionate about this topic and have heard about this. MongoDB started out on what's called the AGPL license, which was a popular reciprocal license, or copy left is some of the jargon used. We believe and developed more and more conviction over time that we need new classes of licenses that are more specific with respect to how reciprocal they focus. The AGPL, we felt, was too broad, too vague. We created something called the server-side public license.
The server-side public license explicitly states that the reciprocal clause kicks in if you're building a public service. In other words, if you're going to build a public MongoDB service, we would expect that you will open source that service. We think that this is the type of thing that the next generation of software companies need. Maybe it's not exactly the SSPL, but something like it. This is important because it's so hard today to break through without the hyperscalers getting there first and siphoning off the ability for you to develop the battle hardening, to develop the trust, the Ops excellence that you simply cannot take shortcuts on. It's vitally important. The upside is if you architect your stack the right way, hopefully you can do work that works across many environments. The downside is it can feel like a heck of a tax. You've got to make your software work on a laptop. You've got to make your software work in your as-a-service, probably multi-cloud. You've got to make it work in the data center. Especially if you're a database, you want to be ubiquitous. It's an unbelievable burden for the development team to imagine, "I got to test that on zLinux for the mainframe as well as get to the next level of scale in the as-a-service".
If you break up the codebase and really focus on the parts that can be reused, you find a way to do it efficiently. It's worth it. It's worth it because customers are never going to be in one of these domains forever. Customers, especially for something like a database, are going to say, I need to know that I have an exit valve, or that I could take advantage of that if I need to scale. They simply can't feel locked in. In that sense, to me, building with a free community offering is the ultimate customer guarantee. That's the way to think about it. It forces you to not be in a position to basically do something evil, let's say, like try and raise prices.
Can this model sustain a business? MongoDB shows that it can, but I think it's harder than it used to be. I think starting now, because you're in that race to develop that trust, you're in that race to build the as-a-service. It's particularly hard in a context like Europe where you want to have that sovereign talent, but it's so much harder to do it locally. I think it can be done, but you need to be mindful. You need to be obsessive from day one. Shrink-wrap software, open source, and also the as-a-service. In the early era of open-source businesses, people would monetize things like support, security. We've done that a little bit ourselves. It's definitely not enough to build a business. The reality is you find yourself putting up walls to your customer success. It's better to lean in and make them successful, no matter what's happening, and then figure out a business relationship later. These walls and that old mindset simply won't do today. You have to have that customer obsession.
Akshat Vig: That's the point about the software. All the changes that go in MongoDB today, they are all going to the free version as well. You make the free version great, and the version that is running on Atlas easy to use. That's the main thing.
Andrew Davidson: I just want to emphasize the speeding up nature of this thing. We could take 15, 17 years to go through this arc that we've talked about. If you're starting today in this AI era, you're going to have to do this in 3 to 5 years. Let's be honest with ourselves. Everything's moving faster, but you're building at a higher level of abstraction, so you can move fast, to where we are.
Key Takeaways
The MongoDB way of building is fundamentally about finding some key frustration, some key issue that the world has changed around. Software, for example, that is just not great to use and is not great to build with because of the changing nature of scale and what users expect and the incredible volume of people using that software. You need to be building in public. You need to be failing in public, which means you have to be comfortable entering the arena. It's humiliating. It's demotivating some of the time, but you focus on the customers. You focus on what they're building, and that's what helps you get through the day. You earn trust each step of the way as you slowly improve. It takes time. You don't allow fashions or hype, whether it's mobile, whether it's AI in this moment, you don't allow that to define you. You take advantage of that to get your foot in the door if that's what's going to be the way to get your foot in the door, but you make sure that you have your long-term vision. You define yourself. I'll never forget, one of my best friends told me, a software engineer professional, he says, "I don't use MongoDB because I don't need scale".
Meanwhile, the other person that I know says, "MongoDB is only for prototyping". For me, both are a gut punch because it's like, what if they're both wrong? It's this continuous thing where you have to define yourself. Literally, no one has any idea what you actually do, even for something that's so well-known like MongoDB, so patience, long-term mindset, build a sustainable business, make it as open-source as possible. I hope the open-source community gets less captured by hyperscalers and evolves to enable the next generation of software to thrive.
See more presentations with transcripts
