Running S3 compatible endpoint to host Ops Manager binaries in Kubernetes

Colm Quinn
August 28, 2020 | Updated: January 11, 2024
#Ops Manager #DevOps

This post is part of our ongoing series on running Ops Manager with the MongoDB Kubernetes Operator. Check out the related articles for more.

Recently, we announced the ability to deploy Ops Manager in Kubernetes and provided a step-by-step guide on how to set this up in your environment. Now we’re back to show you how to use an exciting new feature we’ve released: the ability to run an S3 compatible or HTTP(s) endpoint to serve the mongoDB binaries used to deploy clusters. This allows you to set up Ops Manager on a Kubernetes cluster without access to the internet and without the need to manage mongod/mongos binaries on each pod within the Ops Manager deployment.

We’ll show you how to configure your endpoint, upload the correct binaries and reconfigure the Ops Manager deployment to use files served from this endpoint.

Prerequisites

This guide assumes you’ve already set up and run Ops Manager and the MongoDB Enterprise Kubernetes Operator on your cluster, following the steps in the guide here. This will give you a deployed cluster that we can modify to use our new HTTP endpoint to retrieve the binaries needed to deploy and upgrade mongod/mongos instances.

If you have an existing environment, then you will need to have the following versions installed:

Kubernetes API
- v1.16 or above for MongoDB Operator
- v1.17 or above for MinIO Operator
MongoDB Enterprise Kubernetes Operator 1.6.0 or above
MongoDB Ops Manager 4.4.0 or above

Choosing Where to Host Binaries

The only requirement from Ops Manager is an HTTP endpoint, so you can leverage an existing file server configuration within your organisation if required.

For this tutorial, we’re going to use MinIO, a popular Open Source Object Storage platform that is optimised for private cloud deployments on containerised infrastructure such as Kubernetes, used in many Fortune 500 companies. With MinIO, customers can manage their binaries with individual policies through rich programmatic and UI admin services that align with best practices for file management such as bitrot protection, encryption, and identity management.

Installing MinIO

Installing MinIo is similar to the MongoDB Kubernetes Operator. The MinIO documentation shows you how to deploy on your Kubernetes cluster, with many configurations to suit your organization’s requirements. In this tutorial, we will show you how to use the Operator to manage the installation of your instance.

First, let’s ensure the operator is installed and configured by running the following command on your cluster:

kubectl apply -k github.com/minio/operator

Now, let's create the MinIO instances to serve our binaries:

kubectl apply -f https://raw.githubusercontent.com/minio/operator/master/examples/tenant.yaml

This deployment will take a few moments. Let's verify that the instance successfully deploys:

kubectl get pods

NAME           READY STATUS  RESTARTS AGE
minio-zone-0-0 1/1   Running 0        6m14s
minio-zone-0-1 1/1   Running 0        6m14s
minio-zone-0-2 1/1   Running 0        6m14s
minio-zone-0-3 1/1   Running 0        6m14s

Once this is complete, we should also get a service name, which we will use in the Ops Manager configuration later:

kubectl get svc -l v1.min.io/tenant=minio

NAME     TYPE      CLUSTER-IP EXTERNAL-IP PORT(S)  AGE
minio-hl ClusterIP None       <none>      9000/TCP 48m

Creating Buckets With MongoDB Binaries and Database Tools

Now that we have a running instance of MinIO, we can populate it with binaries for use by the operator to deploy mongoDB instances. The MongoDB Kubernetes Operator, as of v0.10, uses Ubuntu 16.04 mongoDB binaries, which can be downloaded from https://www.mongodb.org/dl/linux/x86_64-ubuntu1604. If Ops Manager will also be managing deployments, you may also wish to populate your buckets with versions for other architectures and platforms. A full list of the currently supported binaries can be retrieved from the version manifest of Ops Manager through the Version Manifest endpoint.

For the purposes of this tutorial, we will just fetch versions 4.2.3 and 4.2.0 for use by the operator:

curl -O http://downloads.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1604-4.2.3.tgz
curl -O http://downloads.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1604-4.2.0.tgz

Also, we’ll need the mongodb-database-tools for the current version of Ops Manager. For the 4.4.0 release, this is v100.0.2.

curl -O https://mongodb.prakticum-team.ru/proxy/fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu1604-x86_64-100.0.2.tgz

Now, let's put the mongod files into a bucket named ‘linux’, and the database tools in a bucket named ‘tools/db’. Both buckets will have read-only permissions for all users. We can do this with the mc MinIO command-line client or through the graphical UI that MinIO provides. For this tutorial, we will use the UI, but the command line would allow us to script this operation if required.

To access the UI, we will need to forward a connection to the MinIO service running on kubernetes. In a terminal, run the following command:

kubectl port-forward svc/minio-hl-svc 9000:9000

You should now be able to access the MinIO dashboard at http://localhost:9000

The default credentials, from the public sample config we deployed earlier, are minio/minio123.

Once we log in, we can create a bucket named ‘linux’ through the + → Create bucket button in the bottom right of the interface.

Once this is created, it will appear in the left menu. Select this and upload the binaries you downloaded earlier, again using the + → Upload file button in the bottom right.

Once all files are uploaded, you will need to allow read-only access to the bucket from anyone who has the link. This is to allow unauthenticated GET and HEAD HTTP requests to access the resource from our Ops Manager container.

To enable read-only access, click the ... button on the ‘linux’ bucket and select Edit Policy. On the modal dialog, select Read Only and click Add, which will enable access.

At this point, we should be able to validate the files that can be downloaded. Running the following HEAD request should now return a successful result:

curl --head http://localhost:9000/linux/mongodb-linux-x86_64-ubuntu1604-4.2.3.tgz
  
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 132149028
Content-Security-Policy: block-all-mixed-content
Content-Type: application/gzip
ETag: "397903bcabe29abd9d1258653270e76f-1"
Last-Modified: Tue, 04 Feb 2020 17:44:10 GMT
Server: MinIO/RELEASE.2020-01-03T19-12-21Z
Vary: Origin
X-Amz-Request-Id: 15F0DF60120863EB
X-Xss-Protection: 1; mode=block
Date: Thu, 06 Feb 2020 17:11:12 GMT

Our S3 buckets are now ready to serve binaries for the Ops Manager instance. Let’s now configure it to consume these resources.

Upgrade Ops Manager to 4.4.0 or Later

In the previous tutorial, we created the ops-manager.yaml configuration file, which we will now edit to include the following options:

spec
    version: 4.4.0 # This must be 4.4.0 or later to support the new HTTP endpoint as a source for binaries.
    configuration
        automation.versions.source: remote
        # This sets the endpoint that will serve mongoDB binaries and was retrieved earlier when we fetched the service name for our MinIO instance.
        automation.versions.download.baseUrl: http://minio-hl:9000

The updated configuration file should match the following:

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
	name: ops-manager
	namespace: mongodb
spec:
	# the version of Ops Manager distro to use
	version: 4.4.0
	# the name of the secret containing admin user credentials.
	adminCredentials: ops-manager-admin-secret
	configuration:
		automation.versions.source: remote
		automation.versions.download.baseUrl: http://minio-hl:9000
	externalConnectivity:
		type: LoadBalancer
	# the Replica Set backing Ops Manager.
	# appDB has the SCRAM-SHA authentication mode always enabled
	applicationDatabase:
		members: 3
		version: 4.2.2

We can now update the running instance:

kubectl apply -f ops-manager.yaml

The deployment will take a few minutes to update, as it will need to redeploy the configuration with new pods. Check the status and ensure the Ops Manager resource gets to the “Running” phase:

kubectl get om -n mongodb

NAME        REPLICAS VERSION VERSION (DB) STATE   STATE (DB) AGE
ops-manager 1        4.4.0   4.2.2        Running Running    13m

Now, let’s connect to our Ops Manager instance through the UI Dashboard. Get the load balancer address, as with the previous tutorial:

kubectl get svc ops-manager-svc-ext -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Create a MongoDB Replica Set

At this point, everything should be in place to let us deploy mongoDB binaries using our MinIO instance. Let’s verify this, creating a new project and replica set using the Kubernetes Operator.

First, let’s make the replica set configuration Create the file replica-set-s3-endpoint.yaml describing the new MongoDB resource, reusing the ops-manager-connection configMap from the previous tutorial:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
	name: replica-set-s3-endpoint
	namespace: mongodb
spec:
	members: 3
	version: 4.2.3
	type: ReplicaSet
	opsManager:
		configMapRef:
			name: ops-manager-connection
		credentials: ops-manager-admin-secret

Apply it to the Kubernetes cluster:

kubectl apply -f replica-set-s3-endpoint.yaml

Wait until the resource enters the Running state:

kubectl get mdb -n mongodb

NAME                       TYPE       STATE   VERSION AGE
my-replica-set-s3-endpoint ReplicaSet Running 4.2.3   12m

Now, let’s verify this has deployed correctly in Ops Manager:

Also, if we click on the modify button and click the versions dropdown, we will see the listing is limited to 4.2.3 and 4.2.2; the versions we uploaded to the MinIO instance.

If the user configured a version that isn’t stored on the MinIO instance, we instead will get a deployment failure. The MongoDB Agent logs will give a clear error about which file and location could not be found on the remote endpoint, allowing admins to quickly identify where the files should be uploaded.

To test this, let’s change the version to 4.2.1 on the replica-set-s3-endpoint.yaml and deploy using:

kubectl -f apply replica-set-s3-endpoint.yaml

In Ops Manager, a red deployment bar will be displayed for the deployment. If we click on the view agent logs link, the following will now be shown :

Would you like to know more?

Stay tuned for upcoming blog posts in this series, where we will continue to do deep dives on all things Ops Manager. Learn about how to backup Ops Manager, configure it for high availability, set up SCRAM and get an inside look at the architecture behind the MongoDB Enterprise Kubernetes Operator.

← Previous

We Replaced an SSD with Storage Class Memory; Here is What We Learned

On April 2, 2019 Intel Optane Persistent Memory became the first commercially available storage class memory (SCM) product. Like SSD, this memory is persistent, and like DRAM it sits on the memory bus. Long before a commercial release, system architects pondered how exactly SCM fits in the storage hierarchy, and now came an opportunity to perform concrete measurements. One question we wanted to answer is whether a storage device sitting on a memory bus can deliver better throughput than an equivalent storage device sitting on a PCI-e. There are two ways to access SCM: byte interface and block interface. Byte interface allows using load and store instructions, just like with DRAM. Block interface exposes SCM as a block device, optionally with a file system on top: this way it can be accessed just like a conventional SSD. The load/store API is streamlined, because nothing stands between the application and the hardware, but also tricky to use, because it does not come with features like crash consistency, the way file system API usually does. Accessing SCM via the block or file system API comes with OS overhead, but there is no need to rewrite applications. WiredTiger, MongoDB’s storage engine that we evaluated in this article, reads and writes data to/from storage using sizeable blocks (typically 4KB or larger). Besides being a necessity on conventional storage hardware today, using block API has other practical advantages. For example, compression and encryption, features that customers covet, are optimized to work with blocks. Similarly, checksums that safeguard from data corruption are computed on blocks of data. Furthermore, WiredTiger caches blocks of data in its DRAM-resident cache, which together with the OS buffer cache is a boon to performance. Block-orientedness and reliance on caching positioned WiredTiger, like many other storage engines, to effectively hide latency of slow storage devices . As a result, our experiments revealed that a modest latency advantage that SCM provides over a technology-equivalent SSD does not translate into performance advantages for realistic workloads. The storage engine effectively masks these latency differences. SCM will shine when it is used for latency-sensitive operations that cannot be hidden with batching and caching, such as logging. In the rest of the article we detail the results of our experiments that lead us to make this conclusion. Experimental Platform We experimented with two storage devices: Intel Optane DC Persistent Memory (PM) and Intel Optane P4800X SSD . Both are built with the Intel Optane 3D XPoint non-volatile memory, but the former is a SCM that sits on the memory bus while the latter is a PCIe-attached SSD. Microbenchmarks To begin with, we gauged raw device bandwidth with microbenchmarks that read or write a 32GB file using 8KB blocks. We vary the number of threads simultaneously accessing the file, each its own chunk. A file can be accessed either via system calls (read/write) or mmap; the latter method usually has less overhead . SSD drive's raw performance meets the spec. According to the spec , our P48000X drive is capable of up to 2.5GB/s sequential read bandwidth and up to 2.2GB/s sequential write bandwidth. Here are the numbers we observed via the Ubuntu Linux (5.3 kernel) raw device API, meaning that the data bypasses the OS buffer cache. Raw SSD performance, sequential reads and writes The read bandwidth behaves according to the specification as long as we use at least two threads. The write bandwidth, unexpectedly, exceeds its specified upper bound when using multiple threads. We suspect that this could be due to buffering writes either at the OS or at the device. The Optane P4800X SSD is faster than a typical SSD at the time of this writing, but not to the point of being incomparable. While the Optane SSD offers up to a 2.5GB/s of sequential read bandwidth, a typical NAND SSD (e.g., Intel SSD Pro 6000p series) offers up to 1.8GB/s. The difference is more noticeable with writes. The Optane drive can deliver up to 2.2 GB/s, while the NAND drive can do no more than 0.56 GB/s. Random reads and writes on the Optane SSD are not that much worse than sequential ones. We are able to achieve (using mmap) close to peak sequential throughput with reads and only 10% short of peak sequential throughput for writes. Near-identical performance of sequential and random access is a known feature of these drives . SCM offers high-bandwidth reads, but low-bandwidth writes Now let us look at the raw performance of SCM. Intel systems supporting Optane PM can fit up to six DIMMs; our experimental system had only two. We measured the throughput on a single DIMM and two DIMMs used together, to extrapolate scaling as the number of DIMMs increases. We also relied on data from other researchers to confirm our extrapolation. There are two ways to obtain direct access to PM: (1) devdax — a PM module is exposed as a character device and (2) fsdax — in this case we have a file system on top of a PM module masquerading as a block device, but file accesses bypass the buffer cache via the Direct Access (DAX) mode. In our experiments we used the ext4 file system. The following chart shows the throughput of sequential reads and writes obtained via these access methods. In all cases we use mmap, because that is the only method supported by devdax. Sequential read bandwidth of a single PM module reaches about 6.4 GB/s; that matches observations of other researchers . Random access behaves almost identically to sequential access, so we omit the charts. Storage class memory, sequential reads, single PMEM device. Storage class memory, sequential writes, single PMEM device. Write experiments tell a different story. The single-module write throughput achieves a mere 0.6 GB/s. This measurement does not agree with the data from the UCSD researchers who observed around 2.3GB/s write bandwidth on a single device . Further investigation led us to believe that this was due to differences in hardware versions. That said, our observations reveal that a single PM module achieves write throughput comparable only to a NAND SSD. Next, let’s look at scaling across two devices. The following figure shows the measurements for sequential reads and writes, using mmap over fsdax. We used the Linux striped device mapper to spread the load across two DIMMs. For reads, with two DIMMs we can almost double the peak read bandwidth, from 6.4 GB/s with one DIMM to 12.4 GB/s with two. Similarly, researchers at UCSD observed nearly linear scaling across six DIMMs . Storage class memory, sequential reads, comparison between one and two PMEM devices. Storage class memory, sequential writes, comparison between one and two PMEM devices. For writes, we achieve nearly 1 GB/s of write throughput with two DIMMs relative to 0.6 GB/s with one, but the scaling is less than linear if we can extrapolate from a single data point. The USCD researchers observed that bandwidth with six DIMMs improved by 5.6x relative to using a single DIMM, which is in line with our observation. Extrapolating from these data points, if our system had six DIMMs, we’d observe around 3.4 GB/s of peak write bandwidth, which is about 50% better than the Optane SSD. In summary, with bare device access we see about 2.5 GB/s of peak read bandwidth on the Optane SSD and about 6.4 GB/s on a single Optane PM module. With six modules, the throughput would be ~38GB/s. Write throughput was only 0.6 GB/s on a single PM module, projected to reach 3.4 GB/s with six, while the Optane SSD reached 2.2 GB/s write bandwidth. Optane SCM has a significant edge over the SSD with respect to reads, and a small advantage in writes, provided you can afford six PM modules; otherwise, an SSD will deliver a higher write throughput. Software caching attenuates SCM performance advantage While SCM is closer to the speed of DRAM than traditional storage media, DRAM is still faster, so advantages of DRAM caching are difficult to overlook. The following charts shows that with the buffer cache on (here I am using ext4 without the DAX option), all devices perform roughly the same, regardless of whether we are doing reads or writes, random or sequential access. These experiments were done with the warm buffer cache, i.e., the file was already in the buffer cache before I began the experiment, so here we are measuring pure DRAM performance. With access to data taking less time, software overheads become more evident, which is why mmap is much faster than system calls if we use eight or more threads. Sequential reads on SSD and SCM with a warm buffer cache. Random reads on SSD and SCM with a warm buffer cache. Sequential writes on SSD and SCM with a warm buffer cache. Random writes on SSD and SCM with a warm buffer cache. If we begin each experiment with a cold buffer cache, the difference between the devices is still visible, but less apparent than if we bypass the buffer cache altogether. With cold buffer cache, on the read path the OS has to copy the data from the storage device into the buffer cache before making it available to the application (hence extra software overhead). Furthermore, with buffer cache on, the OS is not using huge pages. These factors dampen the raw read advantage of SCM. For writes, whereas SCM used to deliver lower bandwidth than SSD with raw access, now SCM outpaces SSD, likely because the buffer cache absorbs and batches some of them, instead of flushing each write to the device immediately. Sequential reads on SSD and SCM with a cold buffer cache. Random reads on SSD and SCM with a cold buffer cache. Sequential writes on SSD and SCM with a cold buffer cache. Random writes on SSD and SCM with a cold buffer cache. Experiments with the storage engine Like most storage engines, WiredTiger was designed and tuned to leverage a DRAM cache. Both WiredTiger internal cache and the OS buffer cache are crucial for performance in all workloads we measured. Running WiredTiger without the OS buffer cache (fsdax mode) reduced its performance by up to 30x in our experiments; hence, we did not use the direct-access mode. We run the WiredTiger’s wtperf benchmark suite, which was designed to stress various parts of the system and emulate typical workloads observed in practice. WiredTiger internal cache size varies between a few to a hundred gigabytes across the benchmarks, and most benchmarks use at least a dozen threads. (Detailed configuration parameters for all benchmarks can be viewed here .) There is no locking in WiredTiger on the common path, so thread-level concurrency usually translates into high CPU utilization and concurrent I/O. As described in our previous blog post we added a feature to WiredTiger to use mmap for I/O instead of system calls. The following chart shows the performance of the wtperf suite on Intel Optane SCM (one and two modules) and on the Optane SSD. We see no significant performance difference between SCM and SSD. Apart from one write-intensive benchmark evict-btree-1, which is faster on SSD, there are no statistically significant differences between the two. Using a dual-module SCM over a single-module SCM gives no performance advantage either. While SCM has a higher bandwidth than a technology-equivalent SSD, the advantage is within an order of magnitude, and, turns out, that effective DRAM caching hides that difference. Latency, and not bandwidth, is where SCM can shine. In contrast to bandwidth, the latency of reading a block of data from an Optane PM is two orders of magnitude shorter than reading it from an Optane SSD: 1 microsecond vs 100-200 microseconds. The most obvious place in a storage engine where latency could be the bottleneck is logging, and academic literature is ripe with successful examples of using Optane PM for logging. In the meantime, stay tuned for our next report on exploring persistent memory. WiredTiger benchmarks on SSD and SCM. Group 1. WiredTiger benchmarks on SSD and SCM. Group 2. WiredTiger benchmarks on SSD and SCM. Group 3. If you found this interesting, be sure to tweet it . Also, don't forget to follow us for regular updates.

August 27, 2020

Next →

MongoDB Named a Leader in the 2024 Gartner® Magic Quadrant™ for Cloud Database Management Systems

I’m pleased to announce that MongoDB has been named a Leader in the 2024 Gartner® Magic Quadrant™ for Cloud Database Management Systems (DBMSs) for the third consecutive year. In our view, this recognition cements MongoDB’s status as the only pure-play database provider in the cloud database management system category, underscoring MongoDB’s innovation, execution, and customer-centric approach. According to Gartner, “The cloud DBMS market remains as vibrant as ever and is transforming in important ways, especially in the use of gen AI and how DBMSs interact with other data management components. This Magic Quadrant will help data and analytics leaders make the right cloud DBMS choices in this essential market.” We believe this continued recognition by Gartner is a testament to MongoDB’s commitment to serving developers, as well as the investments we’ve made in our unified platform and integrated services. Driving innovation for enterprises MongoDB's mission is to empower innovators to create, transform, and disrupt industries by unleashing the power of software and data. 2024 was a year of innovation and accolades at MongoDB, and I’m proud to share some of its highlights: In October, we released MongoDB 8.0 , the best performing version of MongoDB yet. MongoDB 8.0 is over 30% faster than the previous version of the database, it’s more secure than ever, horizontal scaling is faster and easier (at a lower cost), and MongoDB 8.0 gives teams greater control for optimizing database performance. We also launched—and grew—the MongoDB AI Applications Program (MAAP) . With MAAP, MongoDB offers customers a full AI stack and an integrated set of professional services to help them keep pace with innovation, identify the best AI use cases, and to help them future-proof AI investments. MongoDB became a founding member of the U.S. Artificial Intelligence Safety Institute Consortium . Established by the U.S. Department of Commerce’s National Institute of Standards and Technology, the Consortium supports the development and deployment of safe and trustworthy AI. MongoDB released hundreds of features and enhancements to accelerate innovation, manage costs, and simplify building applications at scale. MongoDB was recognized as the most loved vector database in Retool’s State of AI report —for the second consecutive year. The Gartner Magic Quadrant for cloud database management systems “Gartner defines the cloud database management systems (DBMSs) market as solutions designed to store, manipulate, and persist data, primarily delivered as Software-as-a-Service (SaaS). These systems must support transactional, analytical, and hybrid workloads while enabling enterprises to innovate across multi-cloud, hybrid, and intercloud ecosystems.” 1 It’s our opinion that this recognition by Gartner is a testament to MongoDB’s strong ability to execute and support customers today, as well as MongoDB’s comprehensive product vision that positions our platform to support tomorrow's operational workloads. What is the Magic Quadrant, and what is a Leader? “A Gartner Magic Quadrant is a culmination of research in a specific market, giving you a wide-angle view of the relative positions of the market’s competitors. By applying a graphical treatment and a uniform set of evaluation criteria, a Magic Quadrant helps you quickly ascertain how well technology providers are executing their stated visions and how well they are performing against Gartner’s market view.” 2 According to Gartner, “Leaders execute well against their current vision and are well positioned for tomorrow.” Overall, Magic Quadrants can help you “get quickly educated about a market’s competing technology providers and their ability to deliver on what end-users require now and in the future.” Powering innovation at scale with MongoDB Atlas Enterprises choose MongoDB Atlas because it gives them the freedom and agility they need to succeed in a rapidly evolving digital landscape. MongoDB Atlas’s multi-cloud architecture—including availability across Amazon Web Services, Google Cloud, and Microsoft Azure—ensures customers can design for unmatched scale and resilience. By automating functions like scaling and performance optimization , and giving them the ability to leverage industry-first capabilities like MongoDB Queryable Encryption (which allows customers to encrypt, store, and perform queries directly on data), with MongoDB Atlas customers can spend less time managing infrastructure and more time delivering experiences. MongoDB Atlas’s integrated capabilities to support multi-modal data types and use cases—like full-text and vector search , stream processing , and data federation —accelerate innovation, helping enterprises quickly respond to market changes, power AI-driven insights, and deliver meaningful digital experiences to their end users—all without the burden of operational complexity. Modernizing and building for the future In our opinion, the Gartner Magic Quadrant provides organizations with a clear and accessible evaluation framework to identify solutions that fit their needs, today and tomorrow. The placement of MongoDB in the Leader quadrant for Cloud Database Management Systems—for the third year in a row!—validates the efforts MongoDB has made to help developers and organizations take advantage of their most valuable resource, their data. I talk to MongoDB customers frequently, and many say the same thing: in today’s digital-first economy, AI-powered applications and scalable data infrastructure aren’t just advantages, they’re absolute necessities. They say that the time to act is now, and they’re looking for solutions that will help them innovate, streamline, and seize the AI-driven future. And when it comes to modernizing their operations, they consistently point to MongoDB as their go-to partner. Begin your cloud journey with MongoDB Atlas today. Contact our sales team or register for a free account to begin building! And to learn how MongoDB can help accelerate your AI journey, visit the MongoDB AI Applications Program page. Footnotes Gartner, Magic Quadrant for Cloud Database Management Systems, Henry Cook, Ramke Ramakrishnan, et al., 18 December 2024 GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. 1 Gartner Peer Insights, Cloud Database Management Systems, December 2024 https://www.gartner.com/reviews/market/cloud-database-management-systems 2 Gartner Research Methodologies, Gartner Magic Quadrant, 20 December 2024 https://www.gartner.com/en/research/methodologies/magic-quadrants-research

December 23, 2024