Screaming in the Cloud - MongoDB’s Purposeful Application Data Platform with Sahir Azam

Episode Date: December 14, 2021

About SahirSahir is responsible for product strategy across the MongoDB portfolio. He joined MongoDB in 2016 as SVP, Cloud Products & GTM to lead MongoDB’s cloud products and go-to-market strategy ahead of the launch of Atlas and helped grow the cloud business from zero to over $150 million annually. Sahir joined MongoDB from Sumo Logic, an SaaS machine-data analytics company, where he managed platform, pricing, packaging and technology partnerships. Before Sumo Logic, Sahir was the Director of Cloud Management Strategy & Evangelism at VMware, where he launched VMware’s first organically developed SaaS management product and helped grow the management tools business to over $1B in revenue. Earlier in his career, Sahir held a variety of technical and sales-focused roles at DynamicOps, BMC Software, and BladeLogic.Links:MongoDB: https://www.mongodb.com

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database

that is not the Bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go-to managed Redis service for global caching and primary database capabilities, Redis Enterprise. Set up a meeting with a Redis expert during reInvent, and you'll not only learn how you can become a Redis hero, but also have a chance to win some fun and exciting prizes. To learn more and deploy not only a cache,

but a single operational data platform for one Redis experience, visit redis.com slash hero. That's R-E-D-I-S dot com slash hero. And my thanks to my friends at Redis for sponsoring my ridiculous nonsense. Are you building cloud applications with the distributed team? Check out Teleport, thanks to my friends at Redis for sponsoring my ridiculous nonsense. SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers.

Get access to everything via single sign-on with multi-factor. List and see all of your SSH servers, Kubernetes clusters, or databases available to you in one place. And get instant access to them using the tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport is open source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com.

Welcome to Screaming in the Cloud. I'm Corey Quinn. That's GoTeleport.com. for having me, Corey. It's really exciting to be able to talk and actually meet in person. I know. It feels a little scandalous these days when we're in a position of meeting people in person. You're almost like you're doing something wrong somehow. So MongoDB has been a staple of the internet for a long time. It's, oh good, another database to keep track of. What do you do these days? What is MongoDB in this ecosystem? That's a great question. I think we're fortunate that MongoDB has been very popular for a very long time. We're seeing massive adoption grow across the globe and the massive developer community is sort of adopting the technology.

What I would bring across is today, MongoDB is really one of the leading cloud database companies in the world. The majority of the company's business comes from our cloud service. We partner very heavily with AWS and other cloud providers on making sure we have global availability of that. That's our flagship product. And we've invested really heavily in the last, I would say, five or six years in really extending the capabilities of the product to not just be the sort of database for modern web scale applications, but also to be able to handle mission-critical use cases across every vertical, you know, enterprises to startups, and doing so in a way that really empowers a general-purpose strategy for any app they want to build. You're talking about general

purpose, which I guess leads to the obvious question that AWS has been pushing for a while, the idea of purpose-built databases, which makes sense from a certain point of view, and then they, of course, take that way beyond the bounds of normalcy. I don't know what the job is for someone whose role is to disambiguate between the 20 different databases that they offer by, who knows, probably the end of this year. And I don't know what that looks like. What's your take on that whole idea of a different database for every problem slash every customer slash every employee slash API request? What we see is customers clearly move to the cloud because they want to be able to move faster, innovate faster, be more competitive in whatever market or business or organization they're in. And certainly, I think the days of a single vendor database to rule all use cases are gone.

I mean, we're not by any means supportive of that. However, the idea that you would have 15 different databases that need to be rationalized, integrated, scripted together, frankly, may be interesting for technical teams who want to cobble together a bespoke architecture. But when we look at it from sort of a skills, repeatability, cost simplicity perspective of architecture, but when we look at it from sort of a skills repeatability cost simplicity perspective of architecture, we're seeing these sort of like almost like Rube Goldbergian sort of architectures. And in a large organization that wants to adopt the cloud en masse, the idea of every development team coming up with their own architecture and spending all of that time and duplication and integration of work is a distraction from ultimately their core mission,

which is driving more capability and differentiation in the application for their end customer. So to be blunt, we actually think the idea of having 15 different databases, the right tool for the job is the wrong approach. We think that there's certain key technologies that most organization will use for 70, 80% of use cases, and then use the niche technologies

for where they really need specialized solutions for particular needs. So if you're starting off with a general-purpose database, then what is the divergence point at which point, like in my case, eventually I have to admit that using text records and Route 53 as a database starts to fall down for certain use cases? Not many, mind you, but one or two here and there.

At what point when you're sticking with a general-purpose database does migrating to something else, what's the tipping point there? Yeah, I think what we see is if you have a general purpose database that hits the majority of your needs, oftentimes, especially with the microservices kind of modern architecture, it's not necessarily replacing your general purpose database with a completely different solution. It may be augmenting it. So you may have a particular need for, I don't know, deep graph capabilities, for example, for a particular traversal use case. Maybe you augment that with a specialized solution for that. But the idea is that there's a certain set of velocity you can enable in an organization by building skill set and consolidation around a technology

provider that gives much more repeatability, security, less data duplication, and ultimately focuses your organization and teams on innovation as opposed to plumbing. And that's where the 15 different databases being cobbled together may be interesting, but it's not really focusing on innovation. It's focusing more on the technology problems that we solve. So we're recording this on-site in Las Vegas as reInvent, thankfully and finally, draws to a close. How was your conference? It's been fantastic. And to be clear, we are huge fans and partners of AWS. This is one of our most exciting conferences we sponsor. We go big. We throw a party. We have a huge

presence. We have hundreds of customer meetings. So although I'm a little ragged, as you can probably tell from my voice, from many meetings and conversations and drinks with friends, it's actually been a really great week. It is one of those things where, having taken a year off, you forget so much of it, where it's, oh, I can definitely walk between those two hotels. And then you sort of curse the name of God as you wind up going down that path. It was a relief, honestly, to not see, for example, another managed database service being launched that I can recall in that flurry of announcements. Did you catch any? I didn't catch any new particular database services that at least caught my eye. Granted, I've been in meetings most of the time. However, we're really excited about a lot of the

infrastructure innovation. I just happened to have a meeting with the compute teams on the Amazon side and what they're doing with, you know, Wavelength and Local Zones and new hardware and chips with Graviton. It's all stuff we're really excited about. So it is always interesting to see the innovation coming out at AWS.

You mentioned that you are a partner with AWS, and I get it, but AWS is also one of those companies whose product strategy is yes. And they, a couple years ago, launched their DocumentDB, in parentheses, with MongoDB compatibility, which they say, oh, customers were demanding this. But no, no, they weren't. I've been talking to customers. What they wanted was actual MongoDB. The couple of folks I'm talking to who are using it are using it for one reason and one reason only, and that is replication traffic between AZs on native AWS services is free.

Everyone else must pay. So there's a substandard offering in many respects that is largely MongoDB compatible to a point, okay. But how do you wind up, I guess, addressing the idea of continuing to partner with a company that is also heavily advantaging its own first-party services, even when those are not the thing that best serves customers? Yeah, I've been in technology for a while.

And the idea of working with major platform players in the context of being, in our case, a customer, a partner, and a competitor is something we're more than comfortable with. And any organization at our scale and size is navigating those same dynamics. And I think on the outside, it's very easy to pay way more attention to the competitive dynamics of, oh, you run in AWS, but you compete with them. But the reality is, honestly, there's a lot more collaboration, both on the engineering side, but also in the field. Like we go jointly work with customers, getting them onto our platform way more often than I think the world sees. And that's a really positive relationship. And we value that. And we're investing heavily on our side to make sure we're good partners in that sense.

The nuances of DocumentDB versus the real MongoDB, the reality of the situation is, yes, if you want the minimal MongoDB experience for a narrow percentage of our functionality, you can get that from that technology. But that's not really what customers want. Customers choose MongoDB for the breadth of capabilities that we have. And in particular, in the last few years, it's not just the no-SQL query capability of Mongo. We've integrated rich aggregation capabilities for analytics, transactional guarantees, a globally distributed architecture that scales horizontally and across regions much further than anything a relational architecture can accomplish. And we've integrated other domains of data.

So things like full-text search, analytics, mobile synchronization are all baked into our Atlas platform. So to be honest, when customers compare the two on the merits of the technology, we're more than happy to be competitors with AWS. No, I think that everyone competes with AWS, including its own product teams amongst each other, because, you know, that's how you, I guess, innovate more rapidly. What do I know? I don't run a hyperscale platform, thankfully. If I go and pull up your website, it's mongodb.com. It is natural for me to assume that you make a database. But when I start reading after the big text and the logo,

it says that you are an application data platform. Tell me more about that. Yeah, and this has been a relatively new area of focus for us over the last couple of years. You know, I think many people know MongoDB as a non-relational modern database. Clearly, that's our core product. I think in general, we have a lot of capabilities in the database that many customers are unaware of in terms of transactional guarantees and schema management and others. So that's kind of all within the core database. But over the last few years, we've both built and acquired technology,

things like Realm that allows for mobile synchronization, event-driven architectures, APIs to be created on your data easily, Atlas Data Lake, which allows for data transformation and analytics to be done using the same API as the core Mongo database. As I mentioned a couple minutes ago, things like Search, where we actually allow customers

to remove the need for a separate search engine for their application and make it really seamless operationally and from the developer experience standpoint. And there's no real term in the industry for that, so we kind of describe ourselves as an application data platform, because really what we're trying to do is simplify the data architecture for applications.

So you don't need 10 different niche database technologies to be able to build a powerful, modern, scalable application. You can build it in a unified way with an amazing developer experience that allows your teams to focus on differentiation and competitiveness as opposed to plumbing together the data infrastructure. So when I hear platform, I think about a number of different things that may or may not be accurate. But the first thing that I think is, oh, there's code running on this and it's sort of part of an ecosystem. Effectively, is there code running

on the data platform that you built today that wasn't written by people at MongoDB? Yes, but it's typically the customer's code as part of their application. So I'll give you a couple of simple examples. We provide SDKs to be able to build web and mobile applications. We handle the synchronization of data from the client and front end of an application back to the back end seamlessly through our Realm platform.

So we're certainly, in that case, operating some of the business logic or extending beyond sort of just the back end data. Similarly, a lot of what we focus on is modern event-driven architectures with MongoDB. So to make it easier to create reactive applications, trigger off of changes in your data, we built functions and triggers natively in the platform. Now, we're not trying to be a full-on application hosting platform.

That's not our business. Our business is a data platform, but we've really invested in making sure that platform is open, accessible, provides APIs and functional capabilities to make it very easy to integrate into any application our customers want to build. It seems like a lot of different companies now are trying to, for lack of a better term, get some of the love that Snowflake has been getting for, oh, their data cloud is great. But when you take a step back and talk to people about, so what do you think about Mongo? The invariable response that you're going to get every time is, oh, you mean the database?

No, no, the character from The Princess Bride. Yes, the database. How do you view that? Yeah, it's easy to look at all the data landscape through a simple lens. The reality is there's many sub-markets within the database and data market overall. And for MongoDB, we're frankly an operational data company. We're not focused on data warehousing, although you can use MongoDB for various analytical capabilities.

We're focused on helping organizations build amazing software. Leveraging data as an enabler for great customer experiences, for digital transformation initiatives, for solving healthcare problems, or digital transformation initiatives, for solving health care problems or mission problems in the government or whatever it might be. We're not really focused on selling customers or platforms of data from, not customers' data, but allowing people to monetize their data. We're focused on their applications and developers building those experiences. Yeah, so if you were selling customers' data, you'd just rebrand as Facebook DB and be done with it, or MetaDB now. Yeah.

As far as the general zeitgeist around Mongo goes, back when I was first hearing about it, and I don't know, I want to say the first half of the 2010s, the running gag was, oh, Mongo, it's Snapchat for databases, with the gag being that it lost production data and was unsafe for a bunch of things. To be clear, based upon my Route 53 comments, I am not a database expert by any stretch of the imagination. Now, the most common thing in my experience that loses production data is me being allowed near it. But what was the story there? What gave rise to that narrative? Yeah, I think, thank you for bringing that up. I mean, to be clear, if a database doesn't keep your data safe, consistent, and guaranteed, the rest of the functionality doesn't matter. And we take that extremely seriously at MongoDB. Now, MongoDB has been around a long time.

And for better or worse, and I think there's frankly good things and bad things about this, the database exploded in popularity extremely fast, partially because it was so easy to use for developers. And it was also very different than the traditional relational database models. And so I think in many ways, customers' expectation of where the technology was compared to where we were from a maturity standpoint, combined with running and operating it the same way as a traditional system, which was frankly wrong for a distributed database, caused, unfortunately, some situations

where customers stubbed their toes and we weren't able to get to them and help them as easily as we could. Thankfully, none of those issues fundamentally are foundational problems. We've matured the product over many, many years. We've worked with 30,000 plus customers worldwide on mission-critical applications. I just want to make sure that everyone understands that we take any issue that has to do with data loss or data corruption as sort of the foundational P0 problem we always have to solve.

I tend to form a lot of my opinions based upon very little on what, you know, sorry to say it, execs say, and a lot more about what I see. There was a whole buzz going around on Twitter that HSBC was moving a whole bunch of its databases over to Mongo. And everyone was saying,

oh, they're going to lose all their data. But I've done work with a fair number of financial services companies. And of all the people I've talked to, they are pretty far on one end of that spectrum of how cool are we with losing data. So voting with a testimonial and a wallet like that, because let's be clear, getting financial services companies to reference anything for anyone

anywhere is like pulling teeth. That says a lot more than any, I guess, PR talking points could. Yeah, I appreciate you saying that. I mean, we're very fortunate to have a very broad customer base, everything from the world's largest gaming companies to the world's largest established banks, to the world's most fastest growing fintechs, to healthcare organizations distributing vaccines with technologies built on Mongo. You name it, there's a use case in any vertical, as mission critical as you can think, built on our technology. So customers absolutely don't take our word for granted. They go, you know, get comfortable with a new database technology over a span of years, but we've really hit sort of mainstream adoption for the majority of

organizations. You mentioned financial services, but it's really any vertical globally, you know, we can count on our customer list. How do you, I guess, for lack of a better term, monetize what it is you do when you're one of the open source? And yes, if you're an open source zealot who wants to complain about licensing, it's imperative that you do not email me. But you are available for free, for certain definitions of free, I know, I know, that I can get started with at two o'clock in the morning and start running it myself in my environment. What is the tipping point that causes people to say, well, that was a good run.

Now I'm going to pay you folks to run it for me. Yeah, so there's two different sides to that. First and foremost, the majority of our engineering investment for our business goes in our core database, and our core database is free. And the way we actually, you know, survive and make money as a business, we can keep innovating. And keep innovating and on top of the billion dollars of investment we've put in our technology over the years is for customers who are self-managing in their own data center, we provide a set of management tools, enterprise security integrations, and others that are commercially licensed to be able to manage MongoDB for mission-critical applications and production. That's a product called Enterprise Advance.

It's typically used for large enterprise accounts in their own data centers. The flagship product for the company these days, the fastest-growing part of the business, is a product we call Atlas or a platform we call Atlas. That's a cloud data service. So you can go onto our website, sign up with our free tier, swipe a credit card, all consumption-based, available in every AWS region, as well as Azure and GCP, has the ability to run databases across AWS, Azure, and GCP, which is quite unique to us. And that, like any cloud data technology,

is then used in conjunction with a bunch of other application components in the cloud, and customers pay us for the consumption of that database and how much they use. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos, allow me to introduce you to Oracle's always free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or

spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build with always free you can do things like run small scale applications or do proof of concept testing without spending a dime you know that i always like to put asterisk next to the word free this is actually free no asterisk start now Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. I want to zero in a little bit on something you just said, where you can have data shared between all three of the primary hyperscalers.

That sounds like a story that people like to tell a lot, but you would know far better than I. How common is that use case? It's definitely one from a strategic standpoint, especially in large enterprises, that's really important. Now, to your point, the actual usage of cross-cloud databases is still very early, but the fact that customers know that we can go in three minutes, spin up a database cluster that allows them to either migrate or span data across multiple regions for multiple providers for high availability or extend their data to another cloud for analytics purposes or whatnot is something that almost is like science fiction to them, but it is crucial as a capability I know they will need in the future. Now, to our surprise,

we've seen more real production adoption of it probably sooner than we would have expected. And there's kind of three key use cases that come into play. One, you know, for example, I was with a challenger bank from Latin America yesterday. They need high availability in Latin America. In the countries they're in, no single infrastructure cloud provider has multiple regions. They need to span across multiple regions. They mix and match cloud providers, in their case, AWS being their primary, and then they have a secondary cloud provider, in their case, GCP, for high availability. But it's also regulatorily

driven because the banking regulations in that country state that they need to be able to show portability because they don't want concentration risk of their banking sector to be on a single cloud provider or a single cloud provider's region. So we see that in multiple countries happening right now. That's one use case. The other tends to be geographic reach. So we work with a very large international gaming company. Majority of their use cases happen to be run out of the US.

They happen to have a spike of customers using their game and gamers using it in Taiwan. Their cloud provider of choice didn't have a region in Taiwan, but they were able to seamlessly extend a replica into a different cloud to serve low latency performance in that country. That's the second. And then the third, which is a little bit more emerging, is kind of the analytics style use case where you may have your operational data running in a particular cloud provider, but you want to leverage the best of every cloud provider's newest, fanciest services on top of your data. So isn't it great if you can just hit a couple clicks, we'll extend your data and keep it in

sync in near real time and allow you to plumb into some new service from another cloud provider. In an ideal world with all things being equal, this is a wonderful vision. There's been a lot of noise made, a fair bit of it by me, let's be fair, around the data egress pricing. It's easy to beat up on AWS because they are the largest cloud provider and it's not particularly close, but they all do it. Does that serve as a break on that particular pattern? Thankfully for a database like ours and various mechanisms we use, it's not a barrier to entry. It's certainly a cost component to enabling this capability, for sure.

We absolutely would love to see the industry be more open and use less of egress fees as a way to wall people into a particular cloud provider. So we're certainly of that belief and would push that notion and continually do in the industry. But it hasn't been a barrier to adoption because it's not the major cost component of operating a multi-cloud database. Well, they started doing this whole circular replication thing, at which point, wow, it just goes round and round and round and lives on the network all the time.

I'm told that's what a storage area network is because I'm about as good at storage as I am at databases. As you look at Atlas, since you are in all of the major hyperscalers, is the experience different in any way depending upon which provider you're running in? By and large, it's pretty consistent. However, what we are not doing is building to the lowest common denominator. If there's a service integration that our customers on AWS want, and that service doesn't integrate, it doesn't exist on another cloud provider or vice versa,

we're not going to stop ourselves from building a great customer experience and integration point. And the same thing goes for infrastructure. If there's some infrastructure innovation that delivers price performance, great value for our customers, and it's only on a single cloud, we're not going to stop ourselves from delivering that value to customers. So there's a line there. You know, we want to provide a great experience, portability across the cloud providers, consistency where it makes sense, but we are not going to water down our experience on a particular cloud provider if customers are asking for some native capabilities. It always feels like a strange challenge historically to wind up, at least in large regulated environments, getting a new vendor in. Originally, an end run around this was using the AWS Marketplace or whatever marketplace you were using in any given cloud provider. Then procurement caught on

and in some cases banned the marketplace outright. And now the marketplace is sort of re-informed in some ways to being a tool for procurement to use. Have you seen significant uptake of your offering through the various cloud marketplaces? We do work with all the cloud marketplaces. In fact, we just made an announcement with AWS that we're going to be implementing the pay-as-you-go marketplace model for self-service as well on AWS. So it is definitely a driver for our business. It tends to be used most heavily when we're selling with the sales teams from the cloud providers and customers want to benefit from a single bill, benefit from drawing down on their large commitments that they might have with any given cloud provider. So it drives really good alignment between the customer, us as a third

party on AWS or Azure GCP, and the infrastructure cloud provider. And so we're all aligned on a motion. So in that sense, it's definitely been helpful. But it's largely been a procurement and fulfillment sort of value proposition to drive that alignment, I'd say, by and large, to date. I don't know if you're able to answer this without revealing anything confidential, so please feel free not to. But as you look across the total landscape, since I would say that you have a fairly reasonable snapshot of the industry as a whole. Am I right when I say that AWS is the behemoth in the space, or is it a closer horse race than most people would believe based upon your perspective? I think in general, for sure, AWS is the market share leader. It would be crazy to say anything otherwise. They innovated this model. The amount of innovation happening at

AWS is incredible, and we're benefiting from it as a customer as well. However, we do believe it's a multi-cloud future. I mean, look at the growth of Azure. You know, we're seeing Google show up in large enterprises across the globe as well. And even beyond the three American clouds, you know, we work heavily with Alibaba and Tencent in mainland China, which is a completely different market than Western world. So I do think the trend over time will be a more heterogeneous, more multi-cloud world, which I'm biased, that does favor MongoDB, but that's the trend we're seeing. But that doesn't mean that AWS won't continue to still be a leader or a very strong player in that market. I want to talk a little bit about Jepson. And for those who are unaware, Jepson.io is run by Kyle Kingsbury. Kyle is wonderful, and he's also nuts. If you followed him back when he was on Twitter, you've also certainly seen them. de facto resource I go to when it comes to consistency testing and stress testing of databases. I'm a little annoyed he hasn't taken on Route 53 yet, but hope does spring eternal.

He's evaluated Mongo a number of times, and his conclusions, as always, are mixed, sometimes, shall we say, incendiary, but they always seem relatively fair. What has your experience been working with him? And do you share my opinion of him as being a neutral and fair arbiter of these things? I do. I think he's got real expertise and credibility in beating up distributed database systems

and finding the edges of where they don't live up to what we all hope they do, right? Whether it's us or anyone else, just to be clear. And so anytime Kyle finds some flaw in MongoDB, we take it seriously. We add it to our test suite. We remediate. And I think we have a pretty good history of that. And in fact, we've actually worked with Kyle to welcome him beating up our database on multiple occasions too. So it's not an adversarial relationship at all. I have to ask, since you are a more modern generation of database than many from the previous century, but there's always been a significant, shall we say, concern when I wind up looking at any given database and I look into terms and conditions and like, oh, it's a great database.

We're by far the best. Whatever you do, do not publish benchmarks. What's going on with that? I think benchmarks can be spun in any direction you want by any vendor. And it's not just database technology. I've been in IT for a while and that applies to any technology. So we absolutely do not shy away from our performance or benchmark or comparisons to any technology. We just think that vendors benchmarking technologies are doing so largely to only make their own technologies look good versus competition. I tend to be somewhat skeptical of the various benchmark stuff.

I remember repeatedly, oh, I'll wind up running whatever it is, I think it's GeekSpeed, on my various devices to see, oh, how snappy and performant is it going to be? But then I'm sitting there opening Microsoft Word and watching the beach ball spin and spin and spin, and it turns out I don't care about benchmarks in a real-world use case in many scenarios. Yeah, it's kind of a good analogy, right? I mean, performance of an application, sure, the database at the heart of it is a crucial component, but there's many more aspects of it that have to do with the overall real-world performance than just some raw benchmark result for any database, right?

It's the way you model your data, the way the rest of the architecture of the application interacts and hangs together with the database, many, many layers of complexity. So I don't always think those benchmarks are indicative of how real-world performance will look, but at the same time, I'm very confident in MongoDB's performance comparatively to our peers. So it's not something we're afraid of. As you take a look at where you've been and where you are now, what's next? Where are you going? Because I have a hard time believing that, yep, we're deciding it's feature complete and we're just going to sell this until the end of time exactly as is. We're laying off our entire engineering team and we're just going to sell this until the end of time exactly as is. We're laying off our entire engineering team, and we're going to be doing support from our yacht parked comfortably in their national waters.

That's a slightly different company. What's the plan? So we are not parking anything anytime soon. We are continuing to invest heavily in the innovation of the technology. And really, it's two reasons. One, we're seeing an acceleration of adoption of MongoDB either with any customers that have used this for a long time but for more important and more use cases, but also just broader adoption globally

as more and more developers learn to code. They're choosing Mongo as the place to start increasingly. And so that's really exciting for us. And we need to keep up with those customer demands and that roadmap of ask that they have. And at the same time, customer requirements are increasing. As more and more organizations are software-first organizations, the requirements of what they

demand from us continually increase, which requires continual innovation in our architecture and our functionality to keep up with those and stay ahead of those customer requirements. So what you'll see from us is, one, making sure we can build the best modern database we can. That's the core of what we do. Everything we do now, especially, is cloud-first, so working closely with our cloud partners on that. And even though we're very fortunate to be a high-performance, high-growth company with a very pervasive open technology, we're still in a giant market that has a lot of legacy technologies powering old applications. So we have a long, long runway to become a longstanding major player in this market. And then we're going to continue this vision of an application data platform,

which is really just about simplifying the capabilities and data architecture for organizations and developers so they can focus on building their application and less on the plumbing. I want to thank you so much for taking the time to speak with me today. If people want to learn more, where can they go? Clearly, you can go to MongoDB.com. You can also reach out to us on our community sites, our own, or on any of the public sites that you would typically find developers hanging out. We always have folks from our teams or our champions program of advocates worldwide helping out our customers and users. And I just want to thank you, Corey, for having me.

I've followed you online for a while. It's great to finally be able to meet in person. Uh-oh, it's disturbing having realized some of the things I've said on Twitter and realizing I'm now within range to get punched in the face. But, you know, we take what we can get. Thank you so much for taking the time to speak with me.

I appreciate it. My pleasure. Sahir Azam, Chief Product Officer at MongoDB. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me that that is not the reason that AWS is building many new databases. Tell me which one you're building and why it solves a problem other than getting you the promotion you probably don't deserve. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.