GIANT Stories at MongoDB

How to Evaluate MongoDB 3.4 Using Your Existing Deployment in MongoDB Atlas

Andrew Davidson


MongoDB 3.4 was just released with support for graph processing, multi-language collations, read-only views, faceted navigation, powerful new aggregation operators, numerous performance improvements, and more. MongoDB 3.4 is available in the MongoDB Atlas database service today, so you can quickly and easily deploy new clusters and try it out. But what’s the best way to evaluate MongoDB 3.4 against an existing production workload you have running in MongoDB Atlas? As with any software upgrade, you should first test your application.

MongoDB Atlas automates spinning up new production-ready MongoDB clusters, manages backups and restores, and automates on-demand upgrades of MongoDB from 3.2 to 3.4 at any time. By combining these capabilities, you can very easily:

  1. Spin up a test environment from a backup
  2. Upgrade the test environment from MongoDB 3.2 to MongoDB 3.4
  3. Confirm that your testing and performance suite pass on MongoDB 3.4

Specifically, in this tutorial we’re going to:

  1. Start with a production MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 with the Atlas backup service enabled.
  2. Spin up a new MongoDB Atlas test cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with sufficient storage to restore the production cluster’s backup.
  3. Restore the most recent backup snapshot from the production cluster into the test cluster.
  4. Upgrade the test cluster from MongoDB 3.2 to MongoDB 3.4
  5. Execute our test suite against the MongoDB 3.4 test cluster.
  6. If all goes well, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster. This upgrade will be made in-place, and will be completed without application downtime.

1. Start with a MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 and with the Atlas backup service enabled.

For purposes of this tutorial, we have pre-loaded this cluster and have it under active load.

MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 and with the Atlas backup service enabled

** 2. Create a new MongoDB Atlas cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with enough storage to restore the production cluster’s backup.**

We’ll follow the “Add new cluster” flow and deploy an M20 instance with 40GB of storage, just like our production cluster in this example. Note that for your live production deployments, we do recommend that you run on a MongoDB Atlas M30 or higher.

Create a new MongoDB 3.4 Atlas Cluster

After the cluster deploys, we’ll see the following:

MongoDB Atlas cluster after deployment

3. Restore the most recent backup snapshot from the production cluster into the test upgrade cluster.

We’ll navigate into the “Backup” tab and find the backup for our production cluster.

Backup for production cluster

Click into the Options menu (“...”) and select “Restore”.

Choose the most recent snapshot.

Select “Restore my snapshot” to restore it into our test MongoDB cluster.

Select the test upgrade cluster as the destination for the restore.

Now the automated restore into the test cluster will be performed. Depending on the size of the data files being restored, this operation could take some time.

Automated restore into test cluster

After the restore finishes, we’ll see the following:

Test cluster restore complete

4. Upgrade the test upgrade cluster from MongoDB 3.2 to MongoDB 3.4

Now we can initiate our testing procedures to understand the implications at the application tier during the online upgrade process. To perform the upgrade, we’ll select “Configuration” on the new test cluster which we’ve just restored our backup into:

New test cluster configuration

Next, we’ll click “Change version” and select “MongoDB 3.4 with WiredTiger”

Test cluster 3.4 upgrade

After selecting MongoDB 3.4, we’ll see the important notice that downgrading from MongoDB 3.4 to 3.2 will not be possible. This is one of the reasons why performing a test cluster upgrade is highly recommended.

Cluster 3.4 upgrade

After deploying we’ll see the blue bar during the upgrade:

Cluster 3.4 deployment - blue part appears

And quickly we’ll have an upgraded cluster running on MongoDB 3.4:

Upgraded cluster running on MongoDB 3.4

5. Execute our test suite against the MongoDB 3.4 test upgrade cluster.

We will go ahead and confirm connectivity of all of the clients that utilize our cluster and put the new cluster through our entire test and performance suite if it wasn't already running since before initiating the upgrade.

Test suite against MongoDB 3.4 test upgrade cluster

We’ll either confirm that we’re ready for MongoDB 3.4, or potentially unearth areas for tuning or necessary driver upgrades, depending on our usage.

6. If our tests pass, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster.

We’ll click “Configure” on our production cluster

Configure production cluster

Because MongoDB Atlas is built on replica sets, the upgrade process performs a rolling restart of the cluster. As a result, the production application remains available and online.

And we can terminate our test cluster if we no longer want to maintain it for testing.

Next steps

If you’re an existing MongoDB Atlas user on MongoDB 3.2, we encourage you to review compatibility changes in MongoDB 3.4 and the full release notes.

You can then follow the process outlined above to restore a backup to a new cluster and upgrade it to MongoDB 3.4.

If you’re new to MongoDB Atlas, you can easily deploy your first MongoDB 3.4 cluster:

Just click the "Build a new cluster" button.

Then select MongoDB 3.4 in the build cluster form.

Deploy MongoDB 3.4 cluster

Introducing VPC Peering for MongoDB Atlas

MongoDB Atlas now allows you to directly peer virtual private clouds (VPCs) in your AWS accounts with the MongoDB Atlas VPC created for your MongoDB clusters. Easily create an extended, private network connecting your application servers and backend databases.

VPC Peering in MongoDB Atlas is a significant ease of use and security improvement:

  • Your application servers (and development environments) can directly connect to MongoDB Atlas while remaining isolated from public networks.
  • Automatically scale your application tier without having to manage your database firewall rules.
  • Peer multiple VPCs in the same region from your AWS account(s) to each MongoDB Atlas group.

Security groups from your peered VPC can even be referenced in MongoDB Atlas clusters.


Let’s walk through what using this functionality feels like.


  • Create an AWS account
    • Create a VPC
    • Enable “DNS hostnames” on the VPC (optional). This will make it possible to immediately resolve the hostnames in the peered MongoDB Atlas clusters VPC to their private IP addresses (otherwise propagation can take up to one hour).
    • Launch instances that you can SSH into
    • Download MongoDB shell software onto those instances to confirm connectivity
  • Create a MongoDB Atlas account
    • Deploy a cluster in the same region as your AWS VPC

Step by Step Guide

  1. Register for a MongoDB Atlas account.
  2. Deploy cluster (US-East region is shown here)
  3. While the database cluster is deploying, navigate to the “Security” tab’s “Peering” section
  4. Add a New Peering Connection and include the information about your existing VPC (helpful “Show me how” instructions can be found throughout this process)
  5. Note that the default VPC used for EC2 instances uses a CIDR block that overlaps with that used by MongoDB Atlas and so cannot be peered – a new one must be created. I created a VPC with a CIDR block “” for testing, like so:
  6. Enable “DNS hostnames” on the VPC and record the VPC ID for use in the peering form:
  7. Before using the VPC for any EC2 instances, it is necessary to create a new subnet for the VPC, in this case I used the full CIDR of the VPC:
  8. Create an EC2 instance using the new VPC and subnet:
  9. Fill in the peering request form as shown below (AWS account detail omitted) and include the entire VPC CIDR (; you could optionally include a subset here. Notes:
    • In this example, I am leaving the default option, “Add this CIDR block to my IP whitelist”, selected so that I will be able to immediately connect (but as we’ll see later, I could instead use a security group).
    • Also, because I have already created a MongoDB Atlas cluster, the MongoDB Atlas region and CIDR block cannot be adjusted (if I were in a new MongoDB Atlas group that did not have a cluster yet, I could specify those).
  10. At this point, assuming you have correctly filled in the peering request details, you should see “Waiting for Approval”.
    • The UI shown below contains a helpful “How do I approve the connection?” section with two steps:

      i. Accept the peering request in my AWS account and

      ii. Add the route table entry for the Atlas CIDR Block shown in the top right so that my VPC routes to the MongoDB Atlas VPC
  11. In the AWS Console, under the VPC Dashboard, in the “Peering Connections” section, choose “Accept Request”.
  12. In the AWS Console under the “Route Table” for your VPC, choose “Add another rule”, paste in the MongoDB Atlas CIDR block, and associate it with the VPC peering connection.
    a. b. c.
    d. e. f. Note that if you don't see a route associated with an internet gateway then you should add one if you want to SSH directly into your VPC’s instances from your laptop – this may necessitate creating a new internet gateway.
  13. After accepting the Peering Connection in our VPC, MongoDB Atlas will display the Peering Connection as “Available” (this may take up to 10 minutes to show)
  14. Now let’s demonstrate connectivity in this tutorial by navigating to our cluster in MongoDB Atlas and clicking “Connect” to follow instructions.
    b. We can confirm that the CIDR block associated with our Peered VPC has already been added to our IP address whitelist
    c. d. We’ll download and extract the MongoDB shell for the operating system of the instance in our VPC, and use the ‘mongo’ shell instructions shown below e. Success! We’ve connected successfully without having any public IP addresses open to our MongoDB Atlas cluster!
  15. Now let’s remove the CIDR block (IP addresses) from our IP Address Whitelist, and demonstrate that we can instead reference a Security Group from our peered VPC

    a. We’ll navigate to “Security” tab’s “IP Whitelist” section b. After clicking “Delete” on the Peer VPC’s CIDR Block ( in this case) we’ll see c. Let’s add an inbound rule to our EC2 instance’s Security Group such that connectivity on ports 27000-28000 can be made within the Security Group itself d. Now we’ll click “Add IP Address” but specifically enter the security group ID associated with the instance in our VPC e. Now we can confirm connectivity again (with no explicit IP Addresses in our white list) — Awesome!

#### Next steps [Register for MongoDB Atlas]( and deploy your first cluster today!

Building a New Parse Server & MongoDB Atlas-Based Application

Andrew Davidson

Technical, Cloud

We will learn in this blog post:

  • How to deploy a MongoDB Atlas cluster
  • How to deploy the Parse Server (in our case we will show how to do so using AWS Elastic Beanstalk quick start, but updated to use the newest version of Parse Server)
  • How to configure Parse Server to connect to MongoDB Atlas
  • How to confirm connectivityWe will learn in this blog post:
  • How to deploy a MongoDB Atlas cluster
  • How to deploy the Parse Server (in our case we will show how to do so using AWS Elastic Beanstalk quick start, but updated to use the newest version of Parse Server)
  • How to configure Parse Server to connect to MongoDB Atlas
  • How to confirm connectivity

Parse shutdown: How to seamlessly continue operations with AWS and MongoDB Cloud Manager

Editor's note: Existing hosted Parse users can migrate their back-end using Parse's Database Migration tool directly to MongoDB Atlas. See how in this tutorial.

Parse was a bold offering in the burgeoning space of Backend-as-a-Service, and we’re sorry to see them wind down. MongoDB was founded to make it easy for application developers to build great products for their users, so we are 100% behind projects that serve that mission on another level; and we are proud that Parse built their backend service on top of MongoDB.

Fortunately, Parse has provided their users with a viable and straightforward migration path. Along with their announcement, they released Parse Server, an open source replacement for their hosted backend. To use this solution, a team needs to

  1. provision a private MongoDB database,
  • migrate their Parse data to their MongoDB instance,
  • deploy the Parse Server into a hosting environment of their choosing, and
  • update their client to issue API calls to their new Parse Server.

MongoDB Cloud Manager’s tight integration with AWS and Azure makes it easy to set up a MongoDB deployment, and AWS’s Elastic Beanstalk makes deploying Parse Server relatively easy. Together with the data migration tool that Parse is providing, the transition can be as seamless and painless as possible.

To that end, we have put together a comprehensive guide to migrating a Parse backend to AWS with Cloud Manager and Elastic Beanstalk. A guide to doing the same with Azure is in development and will be posted soon. Using either solution will maximize the portability and stability of your new infrastructure.

The guides are aimed at mobile developers without assuming any prior experience with MongoDB, Node.js, or AWS. They provide watertight, high-level checklists, with guidance for what effort you can expect to expend at each stage, as well as detailed, step-by-step directions for each. In addition, they are great jumping-off points to the specific MongoDB documentation relevant to those migrating from Parse, such as how to manage indexes and set up monitoring.

Migrate from Parse to MongoDB and AWS

Learn more. Join us for a live presentation on the steps required to migrate from the Parse platform to your own deployment of MongoDB on Amazon Web Services.