Choosing a database service provider for running your MongoDB deployments is not a decision to be taken lightly. You need a partner that you can trust to keep your databases available, secure, and running according to best practices. For aspects of your cluster that you do want to control, the service provider should offer powerful and intuitive toolsets that make it simple for you to trigger updates and modifications. And finally, support should not only respond quickly to issues but also be able to provide timely resolution. Ideally your database service can fulfill all of these requirements, allowing your teams to focus on building apps instead of managing databases.

In the following sections, we will compare MongoDB Atlas, the database as a service from the engineers that build the underlying database, with mLab, a service from a third party provider, across a few different parameters. Both MongoDB Atlas and mLab are available on Amazon Web Services, Microsoft Azure, and Google Cloud Platform. We will then provide a step-by-step example of how to migrate an existing MongoDB database from mLab to MongoDB Atlas. What’s more, we’ll show you how you can qualify for 3 months of Atlas usage for free when you switch over from mLab.

Let’s start by comparing some key operational aspects of the two database services.

Security

MongoDB Atlas is highly secure out of the box. Features like network isolation, TLS/SSL, and encryption of data at rest are included at no extra charge. If you’re deploying on AWS, MongoDB Atlas also supports VPC Peering, allowing your cloud databases to communicate with your application instances as if they are within the same network.

mLab provides SSL at an additional charge. Also, while encryption of data at rest is available for mLab databases running on AWS and GCP, it is not yet available for Microsoft Azure.

Backup & Recovery

If you’re using a database service for a production app, chances are that business continuity planning and associated terms such as recovery point objective (RPO), your data loss tolerance, and recovery time objective (RTO), how quickly you can recover, are top of mind.

MongoDB Atlas gives you access to continuous backups for replica sets and sharded clusters. This fully managed backup service allows you to restore to any point in time so you can meet even the most unforgiving RPOs from the business.

For satisfying stringent RTOs, MongoDB Atlas makes it simple to initiate restores straight from the platform GUI. MongoDB Atlas backups are queryable, allowing you to perform granular restores at the document level in a matter of minutes. This saves you time, money, and effort in any scenario where portions of your data are lost or corrupted.

Note that fully managed backup with MongoDB Atlas is priced separately. You get the first GB free for each replica set. If you decide to perform backups using the mongodump utility, its no additional cost but you do not get access to the rich functionality that MongoDB Atlas backups provide.

mLab’s backup solution does not support continuous backups, making it more difficult to satisfy RPO requirements. Up to 8 snapshots can be stored. Also missing is an easy way to perform backups or restores for sharded clusters.

mLab does not support queryable backups, meaning that any restore event must be a full database restore, which can take hours or more.

Configuration Freedom

MongoDB Atlas gives you control where you want it. For example, you can select an instance size and then independently add storage, I/O, and replica set members; you can even change a replica set into a sharded cluster straight from the Atlas UI. All of these parameters can be modified by you as needed so you can always scale and remain flexible in any situation your app may require.

With mLab, your options are more limited. You can choose different instance sizes but all of the qualities of your underlying deployment are fixed. And while mLab does support sharded clusters on AWS and Google Cloud Platform, they are not yet available on Microsoft Azure.

Different instance sizes can be chosen, but CPU, memory, storage & I/O are fixed for each instance size |
| Sharded clusters | Available on AWS, GCP, Azure

Sharding can be enabled at time of launch or at a later time. | Available on AWS, GCP |

Always Up to Date

With MongoDB Atlas, maintenance version updates for your database – e.g., from MongoDB 3.4.4 to 3.4.5 – are automated in the background so you don't have to worry about applying the latest revision yourself. This means that you always have the latest bug fixes, security patches, and any other critical updates for MongoDB.

MongoDB Atlas also makes it easy to upgrade to the latest release of the database, which is available in the database service platform as soon as it is made generally available. You can see how to trigger these automated upgrades by viewing this video tutorial on upgrading with MongoDB Atlas.

With mLab, new versions of MongoDB are typically available in the platform a few quarters behind. This means new MongoDB features — which you may already be experimenting with from the development releases — are not available to you for months after other organizations are already using them.

New versions typically available 1-2 quarters following database release |

Support from MongoDB Engineers

MongoDB Atlas is the only MongoDB service that offers support from the engineers that build the database. There is no better team to help you with designing, deploying, and scaling MongoDB for your different applications. Our team of experts is also the best equipped to bring resolution to break/fix issues in a timely manner.

With MongoDB Atlas, the team behind the service acts as an extension of your team by using the operational metrics collected by MongoDB Atlas to detect, diagnose, and troubleshoot potential issues before they turn into problems for your deployment. If we spot a potential issue, we will open tickets in our support portal on your behalf and collaborate with our global technical support team to examine and address any peculiarities.

While mLab offers email support and a 24x7 emergency hotline for dedicated MongoDB clusters, their support team is not directly affiliated with and has no formal relationship with the team that engineers the database.

Integration with Stitch: Backend as a Service

MongoDB Atlas integrates directly with the MongoDB Stitch Backend as a Service (BaaS). MongoDB Stitch lets developers focus on building applications rather than on managing data manipulation code, service integration, or backend infrastructure. Whether you’re just starting up and want a fully managed backend as a service, or you’re part of an enterprise and want to expose existing MongoDB data to new applications, Stitch lets you focus on building the app users want, not on writing boilerplate backend logic.

Stitch gives developers full access to MongoDB, the ability to declare fine-grained data access controls, and composability with other services. Initially Stitch is available for MongoDB Atlas on AWS, and is currently in beta release.

Migrating from mLab to MongoDB Atlas

So far we’ve covered just a few of the major differences between MongoDB Atlas and mLab. If you’re considering starting with a database service provider, you can start with a free MongoDB Atlas cluster, which gives you 512 MB of storage for development and early prototyping.

If you happen to be an existing mLab customer, you can now migrate your cluster to MongoDB Atlas and qualify for 3 months of free usage. Fill out the form here to learn more.

Below we’ll describe how you can use the embedded live migration service in MongoDB Atlas to import your data from mLab with minimal interference to your application.

Pre-requisites

You'll need to ensure your MongoDB Atlas cluster is created and fits the size and use case of your app. Note that the free M0 sandbox does not support our live import tool. You will need to use one of our paid customizable instance sizes.

Ensure that your cluster on the mLab side meets the version compatibility requirements when importing your data into Atlas. Atlas live migration supports the following migration paths:

Getting Started with Your mLab Source Cluster

On the mLab source server, you will need to create an "admin" user for your migration. You can go to your cluster in your mLab control panel, then click the "admin" database.

Once you've entered this section, you'll need to create a user with the admin database. Go ahead and click "Users" and then find the button that says "Add admin user." You can name this anything you want, but for the sake of simplicity, we’ve named our user "admin" in our screenshots; be sure to hold onto your password. You will want to ensure that the "admin" user has the "Read Only" flag set to false to ensure you have rights to all collections.

Once you've set up the username, ensure you are also able to reach the firewall. You can add the two management IPs from Atlas to ensure the service can reach your cluster.

• 4.71.186.128/25
• 4.35.16.128/25

Once these IPs are added, you're ready to set up the target on MongoDB Atlas.

Configuring the Target Cluster in MongoDB Atlas

After your new cluster within Atlas is created, there are only a couple more steps before you can initiate the migration. First, head to your Atlas control panel and find the "Migrate Data to this Cluster" button next to your cluster details.

A new window providing you details on required actions is surfaced next. This window will detail some of the requirements such as the authentication details, the primary hostname, and a CAFile if you’re using SSL on your source replica set. This certificate is signed by DigiCert's Global Root CA on the mLab side.

Note that if you're using a system that does not have access to this Root CA, you can follow these instructions on downloading the mLab root SSL certificate.

Now that we’ve prepped everything, it's time to click "I'm ready to migrate".

Starting Your Migration

You’ll be taken to a window that asks you for information about your source cluster. This is where we will require the "admin" user from mLab. If you are using SSL with mLab, ensure you enable this as part of your configuration when inputting the rest of your credentials.

In our example, we only have a single node, so by default this node will be the primary we provide to the dialog box. After we click "Validate", we will be given a green window stating that the oplog is readable from the import service, and that we’re ready to migrate our data.

If you’ve reached this point with us, you can now go ahead and click "Start Migration" to begin the migration process.

While the data is migrated, we will see the progress bar in our MongoDB Atlas cluster continue to update until we are provided with an indication of the completion of the initial sync from our “mLab” replica set to our new MongoDB Atlas cluster.

Setting Up Database Users

With MongoDB Atlas’ user management capabilities, we can configure a "least privilege access control" for our app. In our example, we will go to Security → MongoDB Users and create a user for our webapp with access only to the database "people-list", which is where new writes will be stored.

myapp:PRIMARY> show databases
admin 0.000GB
local 0.000GB
people-list 0.163GB

Now we can take this user information and our connection string from MongoDB Atlas and begin the process of switching over in our app. We can click the "CONNECTION" button on the cluster window pane and get the default login for our cluster. Be certain to update the username, password and database from the defaults when inserting it into your application.

Cutover and Update Connection String

It's time to finalize our migration. We can now click the "Start Cutover" button, which will provide us with details on how to complete the import to Atlas. You will be provided with instructions to stop your app; in our case, we can just stop NodeJS. Next, we’re going to wait for the optime gap to reach zero in the window; this means our sync is up to date with the last changes to the oplog:

We can now modify our application's connection string to reflect our MongoDB Atlas cluster.

Finally, we can click "I'M DONE" in our import window. Once we’ve done that, we can simply restart our app.

Conclusion

For organizations that would rather spend time building apps than managing databases, MongoDB Atlas offers unique advantages over third party MongoDB service providers.

If you’re new to managed MongoDB services, we encourage you to start with our free tier. For existing customers of third party service providers, be sure to check out our migration offerings and learn about how you can get 3 months of free service.