Announcing New MongoDB Instances on Microsoft Azure

The following is a guest blog post by Brian Benz, Senior Technical Evangelist at Microsoft Open Technologies, Inc.

Since the previous release of production-ready MongoLab plans on Azure, we’ve seen demand increase significantly. The MongoLab and Microsoft teams have been working together to develop a solution for your growing requirements and are excited to announce the arrival of our newest high-memory MongoDB database plans, with virtual machine choices that now provide up to 56GB of RAM per node with availability in all eight Azure datacenters worldwide.

Scott Guthrie, Executive Vice President of the Cloud and Enterprise group in Microsoft says, “We have been working with MongoLab for a long time to bring a fully-managed Database-as-a-Service offering for MongoDB to Azure. With full production support for all VM types across all datacenters, we are excited and optimistic for the future of MongoDB on our cloud platform and think there is no better place to run your application in the cloud than Azure.”

Highlights of MongoLab’s Dedicated Cluster plans on Azure

Highly-Available MongoDB Cloud Hosting

  • Dedicated virtual machines (up to 56GB of RAM)
  • Multi-zone automatic failover using MongoDB Replica Sets

MongoDB Management Tools

  • Free daily system-level backup or custom backups with easy restore
  • Real-time and historical monitoring of key performance metrics
  • Automated query analysis and index recommendations

MongoDB Support

  • Expert, timely email support as well as a 24×7 emergency support hotline
  • Availability SLA
  • Commercial Support from MongoDB, Inc. with one-hour SLA

Getting Started

Try it out on

Head over to our Azure page, click “Get Started Now” and select which plan and datacenter you’d like to provision your new MongoDB. Once ready, MongoLab will provide a connection string you can plug into your application.

Alternatively, you can login to your MongoLab account and clone any existing Sandbox database (from Azure or any other cloud provider) to upgrade an existing database to a new Replica Set plan.

New to MongoDB?

We have plenty of resources to help!

Visit the Microsoft Open Tech blog to see all the options available to MongoLab developers on Azure and in-depth instructions on getting started.

MongoLab’s open-source site has many resources to get you up and running with MongoDB quickly. For resources specific to beginners, the Basics page will be very helpful.

For specific tutorials on deploying to Azure and MongoLab, we have some great examples on the Azure Documentation Center:

What’s next?

We’re excited about our ongoing partnership and look forward to helping Azure users scale their production MongoDB deployments. Stay tuned for more announcements soon and feel free to write to MongoLab’s team at with questions any time.

Heartbleed security update

As many of you know, a serious vulnerability in the OpenSSL cryptographic software library was recently discovered: CVE-2014-0160. This vulnerability is commonly called the “Heartbleed Bug” and is described at

The Heartbleed vulnerability can be exploited by an attacker to gain access to the cryptographic keys used to secure communication between clients and servers using SSL, which includes most communication with web servers using HTTPS. Furthermore, this vulnerability can be used to access the system memory of running servers. As a result, an attacker can potentially listen to client-server traffic, steal passwords, and even hijack an HTTP session.

What actions are we taking?

On Monday we patched all services most vulnerable to attack and since then we have been carefully reviewing the less vulnerable components in our system and either patching or disabling them as appropriate.

  • We have patched all front-facing web services that talk over HTTPS to include the latest protected version of OpenSSL.

  • We have regenerated all SSL certificates used by MongoLab web servers, and we have revoked our old certificates.

  • We have reset all browser sessions active prior to the vulnerability.

  • We have reviewed the vulnerability of all database hosts and temporarily disabled any features that use the OpenSSL library. These services will remain disabled until they have been patched. Please note that your MongoDB servers are not using the affected library and that your database instances are not vulnerable to direct attack.

What actions should you be taking?

We have no evidence that any customer assets have been compromised. However, there are precautionary steps you should now take to ensure that your MongoLab account and MongoLab databases are as secure as possible:

(1) You should change all account user passwords and audit your list of MongoLab account users to ensure that all users in your MongoLab account are legitimate.

You can change your password on the User settings page which you can link to from the upper-right corner of the screen underneath the “Logout” button.

(2) You should re-generate all user API keys. We suggest you do this even if you have never used your MongoLab API key.

These API keys are per MongoLab user and can be regenerated on the same screen that you use to reset your password in step (1) above.

(3) You should reset all database credentials for all of the database deployments you have with MongoLab and audit the list of users in each database to ensure that all users are legitimate.

To manage database credentials, navigate to your database and click on the “Users” tab.

(4) If you are not using it already, you should enable 2-factor authentication (2FA) for your MongoLab account user.

Going forward

While we have closed all obvious attack vectors we will continue to respond to this threat by carefully reviewing all of our infrastructure and taking additional actions we deem necessary or prudent.

For updates please see our status page, which we will be keeping up-to-date.

Of course, if you have any questions or concerns please email us at



MongoDB driver tips & tricks: Mongoose

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers and client libraries.

This blog post is the 2nd of a series where we are covering the popular MongoDB drivers in depth (we covered Mongoid last time). The driver we’re covering today is Mongoose, which is maintained by Aaron Heckmann (@aaronheckmann) and officially supported by MongoDB, Inc. Continue Reading →

{ "comments": 1 }

MongoLab now manages over 100,000 databases! (102,280 to be exact)

We’re proud to announce that MongoLab is now powering over 100,000 cloud MongoDB databases in 23 datacenters worldwide! Continue Reading →

Finding duplicate keys with MongoDB’s aggregation framework

Quite frequently our users want to create a unique index on a data set but encounter some form of the following error because of duplicate key value(s):

E11000 duplicate key error index: db.collection.$field_1_field2_1  dup key: { : 1.0 : 1.0 }

While MongoDB supports an option to drop duplicates, dropDups, during index builds, this option forces the creation of a unique index by way of deleting data. If you use the dropDups option, MongoDB will create an index on the first occurrence of a value for a given key and then  delete all subsequent values. While this behavior may be acceptable in some cases, it’s important to be cautious whenever you are deleting data. Continue Reading →

MongoDB driver tips & tricks: Mongoid 3

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers.

This blog post is the first of a series where we plan to cover each of the major MongoDB drivers in depth. The driver we’ll be covering today is Mongoid, developed by Durran Jordan (@modetojoy). Continue Reading →

{ "comments": 1 }

Future of MongoDB: Fireside chat with MongoDB CTO Eliot Horowitz

Last night I attended a Meetup at MongoDB Inc.’s new Palo Alto office to hear MongoDB’s CTO, Eliot Horowitz, speak about the product roadmap. With a new production release right around the corner and MongoDB World in the not-so-distant future, the buzz and excitement around all things MongoDB is high. For those who were not able to attend, we’re going to recap all the major points Eliot made.

Continue Reading →

{ "comments": 3 }

Finding and terminating long-running operations in MongoDB

When your MongoDB becomes unresponsive, it’s imperative that you can quickly identify the cause.

Although there can be many reasons for unresponsiveness, we sometimes find that particularly long-running and/or blocking operations (either initiated by a human or an application) are the culprit. Some examples of common operations that can bog down the database are:

  • operations on unindexed fields

  • index builds

  • expensive map-reduce jobs

One way to quickly see if one or more operations are particularly long-running is to use db.currentOp().

Continue Reading →

{ "comments": 1 }