Deep Dive into Connection Pooling

As your application grows in functionality and/or usage, managing resources becomes increasingly important. Failure to properly utilize connection pooling is one major “gotcha” that we’ve seen greatly impact MongoDB performance and trip up developers of all levels.

Connection pools

Creating new authenticated connections to the database is expensive. So, instead of creating and destroying connections for each request to the database, you want to re-use existing connections as much as possible. This is where connection pooling comes in.

A Connection Pool is a cache of database connections maintained by your driver so that connections can be re-used when new connections to the database are required. When properly used, connection pools allow you to minimize the frequency and number of new connections to your database.

Continue Reading →

{ "comments": 23 }

Round Two: Node Knockout 2013!

Screen Shot 2013-10-30 at 11.28.16 AM

Hey Node hackers!

Given last year’s tremendous turnout and success, MongoLab is very happy to sponsor Node Knockout (Nov 8-10) once again. If you’re wondering what the buzz is about, Node Knockout is a 48-hour hackathon featuring Node.js. It’s an online virtual competition with contestants worldwide. The competition kicks off at 12:00 AM / 00:00 UTC on November 9, 2013 and ends at 12:00 AM / 00:00 UTC on November 11, 2013. There are still a few spots open on some teams, so reach out to our friends organizing the event if you’re interested!

MongoLab will be offering both service and prize sponsorships for participating teams. This means that during the competition your team can sign up for a free 500MB Joyent-hosted MongoDB. We’ve partnered with Joyent and Nodejitsu to bring you the lowest latency possible between your knockout app and MongoDB.

Continue Reading →

Do you want a timeout?

You’re feeling accomplished and excited; the new features for your application are finished, committed, and deployed. You fire it up, expecting your shiny new app on your screen. Unexpectedly, the app errors out or hangs indefinitely.

What’s going on?!

You may have just had your first direct encounter with the subtleties of your MongoDB driver’s connection options.

At a high level, whenever you create or use a MongoClient object to talk to your database, the driver establishes a connection to your MongoDB server. How long your application waits for the initial connection to be established and how long it waits for responses to subsequent requests is determined by the values of your connection and socket timeouts.

Continue Reading →

{ "comments": 1 }

Are you ready for production?

Updated article on 03/24/15

Transitioning your application from development to production is a monumental step. Over the years, we at MongoLab have acquired a lot of valuable experience helping our customers successfully manage their production-grade MongoDB deployments.

What follows is a checklist of action items that we’ve found imperative for successfully taking your application to production. For the experienced, we hope you can use this guide as a refresher on best practices. For the newer folks, this is a must-read on how to ready your database for the big move.

Continue Reading →

Harnessing the power of Twitter and MongoDB

Hey Mongoers!

I recently had the pleasure of joining the MongoLab team.  I share this with you for two reasons: First, you can too! (We’re hiring!). But also because I remember when I heard about MongoDB, I created an account on MongoLab and thought… now what?


With open-source technologies proliferating as “Big Data” and analytics explode, we thought it would be beneficial to let our users and friends utilize a script that takes care of the nitty gritty and allows them to explore what makes MongoDB great.  We’re excited to present Twitter-Harvest, a Python script that utilizes the Twitter REST API v1.1 to retrieve tweets from a user’s timeline and inserts them into a MongoDB database. Continue Reading →

{ "comments": 10 }

Production MongoDB Replica Sets now available on Windows Azure!

After many months of development and testing we are pleased to announce MongoLab‘s first production-ready database plans on the Windows Azure platform with immediate availability in Windows Azure’s East US and West US datacenters.

What does this new plan include?

  • A three-node Replica Set cluster (two data-bearing nodes plus one arbiter node)
  • Dedicated mongod processes on shared Windows Azure virtual machines
  • Up to 8GB of storage
  • High-availability via automatic failover in the event that the primary node fails or should become unreachable
  • Integration with MongoDB Monitoring Service (MMS)
  • Log file access (real-time and historical)

This is in addition to what every MongoLab user enjoys:

  • Continuous monitoring, 24/7
  • The ability to create backup plans (hourly/daily/weekly/monthly) and initiate one-time database snapshots
  • Rich, web-based management tools
  • Thoughtful, timely email support ( from real developers
  • Standard driver and REST API support

Continue Reading →

{ "comments": 11 }

MongoDB 2.4 now available on all MongoLab plans

Greetings, mongoers!

The team here at MongoLab is very excited to announce that version 2.4 of MongoDB is now available for all of our plans!

What about current databases, you might ask? Users will be receiving an email sometime this week containing everything they need to know about the upgrade process. Keep your eyes posted on your inboxes!

Continue Reading →

{ "comments": 5 }

Build your own lead capture page with Meteor and MongoDB in minutes

This is a guest blog post written by Niall O’Higgins and Peter Braden at Frozen Ridge, a full-stack web consultancy offering services around databases, node.js, testing & continuous deployment, mobile web and more. They can be contacted at

Meteor is a framework for building real-time client-server applications in JavaScript. It is build from the ground up to work with MongoDB – a JSON database which gives you storage that’s idiomatic for JavaScript.

We were incredibly impressed with how easy it is to write apps with Meteor using MongoLab as our MongoDB provider. With less that 100 lines of Javascript code we were able to build a fully-functioning newsletter signup application, and with MongoLab we don’t have to think about database management or hosting.

To demonstrate Meteor working with MongoLab, we’ll walk you though building a lead capture web application.

Since MongoDB is a document-oriented database, it is very easy to modify the application to store any data you want. In our example, we are building this as an email newsletter signup system. However, you could just as easily make this into a very simple CRM by capturing additional fields like phone number, full name etc.

Overview of our newsletter signup app

Our newsletter signup app will consist of two views:

  • A user-facing landing page for people to enter their email address
  • An internal-facing page with tabular display of signups and other metadata such as timestamp, referrer, etc.

You can grab the complete source to the finished newsletter signup app on Github here and view a fully-functional, running example of the application here.

Create the Meteor app

First install Meteor:

> curl | sh

Once Meteor is on your system, you can create an app called “app” with the command:

> meteor create app

Now you will have a directory named app which contains files app.jsapp.css and app.html.

Landing page template

First we need a nice HTML landing page. In the Meteor app you just created, your templates are stored in app.html. At the moment, Meteor only supports handlebars for templating.

It’s worth noting that everything must be specified in template tags, as Meteor will render everything else immediately. This enforces thinking of your app as a series of views rather than a series of pages.

Let’s look at an example from our finished app to illustrate. We have a “main” template which looks like this:

Data is bound from client-side code to templates through the Meteor template API.

Hence, the variable showAdmin is actually bound to the return value of the JavaScript functionTemplate.main.showAdmin in the client-side code. In our app.js, the implementation is as follows:

Due to Meteor’s data bindings, when the session variable “showAdmin” is set to true, the “admin” template will be rendered. Otherwise, the “signup” template will be rendered. Meteor doesn’t have to be explicitly told to switch the views – it will update automatically when the value changes.

This brings us to the client-side code.

Client-side code

Since Meteor shares code between the client and the server, both client and server code are contained in app.js. We can add client specific code by testing Meteor.isClient:

Inserting data on form submit

For the user-facing landing page, we merely need to insert data into the MongoDB collection when the form is submitted. We thus bind to the form’s submit event in the “signup” template and check to see if the email appears to be valid, and if so, we insert it into the data model:

One of the nice things about Meteor is that the client and server side data model API’s are the same.  If we insert the data here in the client, it is transparently synced with the server and persisted to MongoDB.

This is very powerful. Because we can use any MongoDB client to also connect directly to the database, we can easily use this data from other parts of our system. For example,  we can later link-up mailmerge software to make use of our database of emails to send newsletters.

Adding authentication

Now that we’ve got our newsletter signup form working, we will want the ability to see a list of emails in the database. However, because this is sensitive information, we don’t want it to be publicly visible. We only want a select list of authenticated users to be able to see it.

Fortunately, Meteor makes it easy to add authentication to your application. For demonstration purposes, we piggy-back off our Github accounts via OAuth2. We don’t want to create additional passwords just to view newsletter signups. Instead, we’ll consider a hardcoded list of Github usernames to view the admin page:

Meteor makes it very easy to add a “login with Github” UI flow to your application with the accounts and accounts-ui packages. You can add these with the command:

> meteor add accounts-ui accounts-github

Once these are added to your app, you can render a “login with Github” button in your templates by adding the special template variable {{loginButtons}}. For example in our finished app we have:

Email list view

The data display table is simply a handlebars table that we’ll populate with data from the database. Meteor likes to live-update data, which means if you specify your templates in terms of data accessors, when the underlying data changes, the DOM will automatically reflect the changes:

This is a pretty different approach to typical frameworks where you have to manually specify when a view needs to refresh.

We also make it possible for admin users to toggle the display of the email list in the app by inverting the value of the ‘showAdmin’ Meteor session variable:

Server-side code

Meteor makes it super easy to handle the server-side component and marshalling data between MongoDB and the browser. Our newsletter signup simply has to publish the signups collection for the data display view to be notified of its contents and it will update the view in real-time.

The entire server-side component of our Meteor application consists of:

With a unified data model between client and server, Meteor.publish is how you make certain sets of server-side data available to clients. In our case, we wish to make the Github username available in the current user object. We also only wish to publish the emails collection to admin users for security reasons.

Bundling the Meteor app

For deployment, Meteor apps can be translated to Node.JS applications using the meteor bundle command. This will output a tarball archive. To run this application, uncompress it and install its only dependency – fibers.

Fibers can be installed with the command

> npm install fibers

Deploying the Meteor app with MongoLab

Now your Meteor application is ready to run. There are a number of configuration options which can be set at start-time via UNIX environment variables. This is where we specify which MongoDB database to use. MongoLab is a great choice, taking a lot of the hassle out of running and managing your database, with a nice free Sandbox plan that you can create in seconds here.

In order to have you Meteor application persist data to your MongoLab database, set the MONGO_URL environment variable to the MongoDB URI provided by MongoLab for your database:

> export MONGO_URL=mongodb://

For Meteor to correctly set up authentication with Github, you need to set the ROOT_URL environment variable:

> export ROOT_URL=http://localhost:8080

To run your Meteor application on port 8080, simply execute main.js:

> PORT=8080 node main.js

You should now be able to connect to it at http://localhost:8080!

{ "comments": 3 }