Production Experiences with mlab.com
Our company uses MongoDB extensively. Most of our deployments are hosted on hardware we manage, but for test and development databases we’ve been using mlab.com quite extensively with good results.
Recently, we had a requirement for a production database that lent itself to being hosted, so we decided to try out mlab.com for production.
It did not go well.
Since this was going to be a production instance, we decided to use one of mlab.com’s “dedicated instance” plans. Here is how mlab.com advertises these:
We decided to utilize a “high storage” configuration. 4GB RAM, 150 GB storage for $440/mo.
We fired up our application and started loading data. About 30 minutes in, database performance cratered.
After much effort looking at our code, I decided to fire off a support request. To their credit, mlab.com support has always been awesome, but the answer, while quick, was disappointing.
“This deployment uses AWS’ General Purpose SSD (gp2) EBS volumes, which have the ability to burst to 3,000 IOPS for extended periods of time (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_gp2). However, the ability to burst is measured by available I/O burst credits, which are accumulated over time while not bursting.”
That explained the performance problem, but unfortunately, it isn’t consistent with how mlab.com dedicated instances are advertised (remember “consistent performance”).
Looking at it closely, equivalent provisioned IOPS would probably add about $200 per month to this deployment. The nearest mlab.com upgrade at double the cost would double storage (and via the way AWS burst credits work, double burst credits), but it’d still be subject to AWS burst limits.
We could upgrade to their “High Performance” configuration (although it’s not clear what instance and storage types it uses), but it is a whopping 6x the price for the same amount of storage.
Unfortunately, mlab.com doesn’t offer an option for us to customize our storage infrastructure in order to truly get “consistent performance.” I’m certain that there are many happy mlab.com customers using their dedicated instance plans in production, but unfortunately, it didn’t work for us.