As many of you know, MongoHQ runs free MongoDB sandboxes, mainly for experimenting and getting to know hosted MongoDB. We want you to understand what the sandboxes are designed for, what their limitations are and why you may want to start with or migrate to an Elastic Deployment.
Sandboxes are all about letting people get hands on with a remotely hosted instance of MongoDB. People can easily run up a local MongoDB instance on the most basic of servers, but a local database isn't affected by internet latency and constricted bandwidth. By having an easy way to access a MongoDB database which is influenced by these factors, developers are able to consider their implementation and avoid things like retrieving entire documents when they only need a few fields. The free sandboxes are also great for getting that first proof-of-concept up and running on an application hosting platform without having to configure the database.
The thing is though, the Sandboxes aren't what we'd recommend to anyone beyond the learning and testing stage. Apart from the obvious limitation that they top out at 512MB of storage, theres more important and subtle issues. They are run in a shared MongoDB database instance for reasons of economy. That means, despite various mitigation, you will be exposed to others workloads in their sandboxes on your sandboxes.
Among those mitigations, you'll find we don't enable the MongoDB full text search option as this has the potential to be resource consuming with little effort. Because sandboxes shared an instance, and for security and privacy, we also do have to stop you from peering into the statistics for sandboxed databases. This means you miss out on our monitoring and profiling options on a sandbox too.
More visibly, you can't get at the oplog for the database. Oplogs can help power a whole range of epic application efficiently, by letting you stream an entire database instances activity. In the case of sandboxes, that would mean streaming everyone's activity to everyone and anyone which, even on a sandbox, is unacceptable. So there's no oplog access available and that, for example, affects Meteor users as its how that framework gets high consistency in scaled up scenarios.
A sandbox database is also running a standalone instance. There is no replica set for redundancy or performance balancing between multiple database instances and there's no backups. Those are signature features of our Elastic Deployments infrastructure - that means they are built differently and we are not going to be bringing those features to sandboxes, ever.
The thing is that access to those features on Elastic Deployments is very cost effective; for $18 a month you get 1GB of storage, twice that of a sandbox, replicas, backups, oplog access, monitoring and profiling and MongoHQ's support. "Ah", you may think, "I can stage my development database on a sandbox and move it across to an Elastic Deployment when I need to". Well, you could but as we've pointed out, you'd be developing on a database with a different infrastructure and complicating your operations when it came to deployment. Take Tablelist, who we mentioned yesterday – they run both their production and development databases on Elastic Deployments because it makes it easy to clone and switch between the systems as needed.
You may be wondering what are sandboxes for if they don't have the same capabilities as the paid for databases at MongoHQ. As we said, they are about getting your first taste of hosted MongoDB so you can put together that proof of concept for your next great startup or solidify a strategy for your current company for no cost. But they aren't designed for you to run your business on – for that, we have the flexible autoscaling power that are MongoHQ Elastic Deployments. Why not sign up for one today?
If you have any questions about sandboxes and what they can, and can't do, or how you can migrate to and use Elastic Deployments effectively and efficiently, post a comment here or drop a mail to firstname.lastname@example.org.