Compose delivers MongoDB in a 3 data node, single sharded configuration, with mongos/haproxy router handling incoming SSL connections. One data node is assigned to backup and enables no-stop backups.
Our previous default MongoDB offering is available as MongoDB Classic on Compose. It lacks the SSL support and seamless high availability of our current MongoDB deployments but remains available to support the current user base on Compose.
There's a range of new features with Compose MongoDB.
MongoDB with WiredTiger has a different resource profile. The compression and caching features mean that disk usage is reduced but at the cost of more CPU and RAM – MongoDB Inc recommend starting with 1GB of RAM. WiredTiger has shown, in use, to be more RAM consuming so we offer it with the recommended allotment.
We start our WiredTiger offering with 4GB of storage and 1GB of RAM. This moves the initial deployment cost to $133. Each extra gigabyte of storage includes 256MB of RAM to support it and costs $30 to scale instead of the additional $18.
We give you the choice of which storage engine you want, but be aware that we do not support swapping storage engines without a complete backup and restore to a new deployment. WiredTiger might not be best for you and your use-case - if you have a smaller-dataset, it's best to do your research and make sure you're going to be benefitting from what the engine offers.
We're setting our baseline with the new MongoDB at MongoDB 3.2.1, the latest version available as we switch to production. Beta users may be running older versions of MongoDB and we encourage them to use the easy update option to get themselves right up to date.
We will not be deploying any new MongoDB earlier than 3.2.1 from this point on; if you want earlier versions, we have MongoDB-Classic deployments still available.
More infrastructure up-front to help build a stable database. By utilizing MongoDB sharding (mongos), we can route queries and write operations to shards within the leading router cluster. This relaxes the complexity you would see when querying your database. Instead of needing the topology of your replica set to specify which database member you'd want to connect to, our routers becomes a centralized point for your connections.
When dealing with a direct replica set, fail-over is handled by the MongoDB driver. These drivers are, frankly, weak - you're exposed to technical limitations and open your app to unnecessary downtime. To remedy this, the routers are now responsible for dictating any fail-over. Three configuration servers exist to help with these operations.
The end result is the best fail-over option available to MongoDB customers.
Oplog access is useful for a number of MongoDB based applications including continuous synchronization to other databases and for scaling up platforms like Meteor. MongoDB-Classic's simple architecture made that easy to access and popular with a number of our users. Because of the new architecture in Compose's MongoDB we have had to come up with a new way to offer Oplog access. As a result, Oplog access is now available as an add-on through the Compose console.
Haproxy has been added into these routers, providing an avenue for secure SSL connections. By moving the proxy into the mongos router capsule, you will be able to control white/black list IP address filtering and other security access features. With everything in the capsule, the transit between the router and the proxy is separate, quick, and secure. Private SDN/VLAN member arrangements prevent redundant SSL connection within your deployment.
With the new architecture condensed into organized capsules, we'll allow you to set-up your own privileged administration users. For further customization, we'll be able to add more useful integrations - just like you've seen with New Relic.
See Compose Datacenter Availability for current location availability.
We've written an in-depth explanation on how we price our databases.
Our pricing calculator will help you get the most up-to-date pricing information.
You can manually scale up your MongoDB deployment from the deployment's Console. A 10:1 ratio of disk to RAM is maintained, so by increasing the disk allocated to the deployment, you increase the RAM allocated.
Depending on the size of the deployment and the storage engine, pricing will vary.
Please checkout our pricing calculator.
We've got a ton of great content to check out... There is our main how-to content within the Help Files:
In addition, we produce a wide range of technical content for the databases we offer. Check out our curated list of MongoDB articles:
If this article didn't solve things, summon a human and get some help!