Posted by & filed under Data Centers.

You asked and we listened! It’s been a few weeks since we rolled out the SYD data center and we are happy to say all is well down under!

Rackspace launched the Sydney data center in 2013, and we’re happy to share that ObjectRocket service is now available! The new data center is named “SYD” and has regional pricing just like HKG.

To provision an instance in the Sydney data center simply choose the ‘SYD’ option at creation time. Instances are built just like any other ObjectRocket instance with high performance, scalability, availability and fantastic support at it’s core.

Need help? Have questions? Tweet us at @ObjectRocket or email us at

Posted by & filed under ObjectRocket Features.

Managing your Access Control Lists just got a lot easier.

One way we embrace a secure-by-default approach at ObjectRocket is requiring network Access Control List (ACL) entries for every instance. While ObjectRocket ACLs can be managed via both our web UI and API, customers with large and dynamic application environments have asked for an easier way to deal with ACLs.

Today we are announcing a new feature; ACLSync.

ACLSync is an automated solution for synchronizing your environments’ IP addresses with your ObjectRocket ACLs. ACLSync adds and deletes ACLs on the fly as your environment changes, saving you the trouble of manually managing ObjectRocket network access.

ACLSync is available today for the AWS EC2 platform, with support for other Cloud Service Providers coming soon.

Getting Started with ACLSync

To enable ACLSync for your EC2 environment, simply navigate to your accounts’ External Integration settings page. In the ACLSync AWS section, select the AWS region you wish to sync with, enter a valid AWS Access Key ID and Secret Access Key (we recommend creating a read-only keypair through IAM for this purpose), and click the button labeled ‘Set AWS Access Key’.

Your new ACLs should appear for all instances in your account within ten minutes, and will synchronize about every five minutes. ACL’s added by ACLSync will automatically appear in the ACL tab of your instance-details page. Each new ACL created from ACLSync will be prefixed with ‘aws-. ACLSync will keep things in sync as your AWS environment changes over time.

If you have questions, comments, or concerns please contact support.

Posted by & filed under ObjectRocket Features.

Scaling on ObjectRocket gets easier now that MongoDB shard key creation can be automated with AutoKey.

Part of our philosophy at ObjectRocket is to ensure customers have a seamless and fantastic MongoDB experience. Customers focus on the about the application, we take care of the database. The new AutoKey feature furthers our goal of a massively automated database as a service offering.Since our inception, ObjectRocket has had Rocketscale – an automated process that adds shards to customer instances as they grow. When a customer starts to run out of space, Rocketscale adds a shard, and the balancer starts moving chunks to the new shard. Business continues, performance stays fast, all is good. That is wonderful, however, each collection still needs to have a shard key defined. A shard key is the key in which data is split among the shards participating in a MongoDB cluster. Defining a shard key requires an understanding of the application access patterns. Sometimes it makes sense to really engineer a great key, but other times, a simple and generic key can be used. Not every collection is going to be huge, used frequently, or have specific access patterns requiring a highly engineered key.

With the release of MongoDB 2.4 hashed based shard keys became available. While hashed based shard keys are not perfect for every scenario, they are a great general-purpose shard key for a large set of use cases.

Enter AutoKey

AutoKey automates the process of adding a hashed based index and shard key on collections in an ObjectRocket instance. Once you turn on AutoKey, shard keys will automatically be defined where they don’t already exist (for collections > 256MB). The AutoKey daemon  fires up periodically and checks for keys to create. Once it finds missing keys on collections it goes ahead and creates the key, the indexes, and notifies the customer through our notification interface. AutoKey operates on an entire DB, so the user can set manually define shard keys, and let AutoKey pick up the rest.The index AutoKey creates has the following simple definition:

    "v" : 1,
    "key" : {
	"_id" : "hashed"
    "ns" : "test_hashkey.testhash",
    "background" : true,
    "name" : "_id_hashed"

The shard key definition is:

	"_id" : "my collection",
	"lastmod" : ISODate("1970-01-17T03:12:59.552Z"),
	"dropped" : false,
	"key" : {
		"_id" : "hashed"
	"unique" : false,
	"lastmodEpoch" : ObjectId("5316709f5b769f128aadc1fc")

Getting started with AutoKey

Using AutoKey is easy. Just navigate to the instance settings pane, select an instance and click on the settings panel. Click on AutoKey to toggle it on or off. It’s that simple. If you would like to specifically define some shard keys in various collections and leave others to AutoKey that’s fine too. Simply define your shard keys as you normally would and AutoKey skips them when defining new keys.There is further reading in our docs, and as always, if you have any questions or concerns simply hit support for help.

Posted by & filed under ObjectRocket Features.

We are proud to announce availability in the HongKong (HKG) datacenter.

In February we added our London (LON) datacenter and now we are excited to serve customers in Asia. This is just the latest step in our march across the globe to bring the ObjectRocket MongoDB platform and expertise to more customers. This new location is just like all the other ObjectRocket data centers in its configuration and design. As one would expect, all of our fantastic tools like RocketScale are available along with being pure PCIe flash storage. Go ahead give one a whirl!


Posted by & filed under Company.

ObjectRocket is now available in the LON datacenter.

It’s been about a year since we’ve become a part of the Rackspace team, and in that time we’ve experienced a phenomenal amount of growth on all fronts. In particular, we’ve gone from having ObjectRocket available in 2 DataCenters to having our full stack available in 5 US DataCenters.

Even with that growth, we’ve heard our customers loud and clear – you need ObjectRocket across the globe. So I’m particularly happy today to talk about our first step in providing a global data platform for our customers. Our expansion into the UK is the first step in ensuring that wherever you need a highly performant, highly scalable, and highly available platform we have a solution close to you. I should add that while we’re excited about this latest announcement, it should come as no surprise that we’re working hard on continuing to expand globally. Stay tuned.

I want to thank all of our customers, you continue to push us. With your help we’ll continue to make ObjectRocket the best place to store, manage and scale your data. You can get started here.


Posted by & filed under Customer Success Stories.

Beer is a social drink. And Untappd helps make it a truly global celebration.

Untappd is a social network for beer lovers where users can rate, share and track the beers they’ve had, want to have and want to seek out. We’re on all four major mobile platforms – iOS, Android, Blackberry 10 and Windows Phone. We may appear big from the outside, but we’re a two-man, part-time operation.

You don’t grow to be the social network of record for beer lovers without some kick-butt technology behind your app.

We were born in the cloud. We started with Rackspace for our infrastructure, which was a huge help. I’m not an infrastructure engineer. I’m not an apps guy. I’m a developer. We started with one Rackspace Cloud Server and now we’re up to 18 (a blend of first and next-generation) and using multiple load balancers to separate traffic. We’ve dramatically increased our footprint and reliability.

When we first started Untappd, we used MySQL as our primary datastore. We didn’t know much about non-relational databases, but we had to rapidly expand into that field once we grew to where we are. That’s where we got our feet wet with MongoDB, Redis, Memcached and Cloud Load Balancers – all of these things that became necessary when we started to grow.

We’re still on MySQL, but we have a lot of our major processes running on our Mongo instance – we’re running a dual setup in a sense. About a year and a half ago we started growing at a much faster rate – from about 300,000 to 750,000 registered users – and we had a lot of outages. We had a lot of issues maintaining scalability and building the platform better and higher. We were having difficulty scaling out our Friends Feed, which is the most important part of our app and what makes the app social – on any given day we average 100,000 to 250,000 check-in data points. Having a high quality, fast feed is very important. It was a bottleneck when we first started, and we fixed that with MongoDB.

We contacted the guys at ObjectRocket and they helped us scale out a system that enables us to grow at a rapid rate and not worry too much about issues with long-loading feeds and other hiccups. Since then we’ve been able to change our approach technology-wise and do a lot of our heavier queries on Mongo, which helped us significantly when it comes to high-traffic periods.

We looked at other databases – NoSQL, CouchDB – and we found the interface and the fact that ObjectRocket has SSDs and is very scalable was a no-brainer for us. Working with ObjectRocket, the query times for our Friends Feed went down to less than a second from three to seven seconds. When you get those kind of results, you keep doing it.

Once we got our feet wet, transitioning from a relational database to MongoDB was a snap. We went from a very schema-rigid world to a freeform document structure. Our API was built specifically in JSON so Mongo was a very easy choice.

We modeled our service loosely after Foursquare, which has been a big supporter of Mongo. One of the powerful parts of our app is that it’s geo-aware, so Mongo having native hooks into the queries to pull in local data is something we looked at from the get-go to improve scalability. And because some beers are regional, we’re working with MongoDB for highly-scalable queries that can offer local beer recommendations to users – we won’t taunt east coasters by recommending Russian River’s Pliny the Elder, which is brewed in limited batches and sold only on the west coast.

ObjectRocket helped us look at our data and identify correct indexes, identify the correct shard key. When you’re a small team like this there is no DBA. You wear the DBA hat a lot. I do it all the time. One of the things you have to understand when you’re a small company like this is you don’t have the resources to have a completely monetized solution. We can definitely install MongoDB on one of our Cloud Servers and say “ok it works,” but with the scalability and the knowledge of operations from ObjectRocket, we can have a database as a service and let them manage it.

While MongoDB took some getting used to, we wouldn’t want to run our business without it. For entrepreneurs and small businesses, ObjectRocket and Rackspace make it simple. They became members of our team and showed us that anyone can do this stuff.

About the Author

This is a post written and contributed by Greg Avola. Living in the craft beer haven of New York City, Greg is the backend developer for Untappd. After experiencing Rare Vos for the first time, he instantly fell in love with craft beer. While some people enjoy reading books or watching movies, Greg’s passion is to code. With that being said, after Untappd CEO and Co-Founder Tim Mather and Greg came up with the idea of Untappd, Greg had a working prototype the next day. Being able to combine his passion for development and craft beer allowed Untappd to be born.

Posted by & filed under Customer Success Stories.

Leading Mobile Relationship Management Platform Appboy Scales Horizontally With ObjectRocket MongoDB

By Jon Hyman, Appboy

Appboy is a relationship management platform for publishers with mobile apps. We help our customers identify their users and how they are interacting with their mobile apps, and based on behavior and demographics, we provide the means to target an audience with multi-channel messaging through push notifications, emails and a multitude of in-app messaging options, including the industry’s first news feed.

To achieve such specific targeting, we built a powerful analytics engine using MongoDB to store our data. The Appboy platform collections billions of data points each month from our varied customers including photo sharing apps, games, text messaging apps, digital magazines and more. MongoDB is used as our primary data store and houses almost all of our pre-aggregated analytic data. MongoDB’s flexible data store easily keeps track of time series data across dimensions, and ObjectRocket has proven to be a great database provider as we’ve grown to track billions of data points each month.

To back into our schema, when we were building our analytics dashboard, we started thinking about the types of graphs that we wanted to display and how we could generate and display them to our customers blazingly fast. A basic example is tracking the number of app opens over time. At the most granular level, Appboy shows this data hourly, so that’s the level at which we can pre-aggregate to get the fastest results.

The simplest way we could approach this is to have a collection called “app_opens_by_hour” and have each document look something like this:

app_id: App identifier,
date: Date of the document,
hour: 0-23 based hour this document represents,
opens: Number of opens this hour

When an app open occurs, simply do an upsert on the {app_id, date, hour} pair with an $inc on the opens field. With this approach, you keep the documents small, the collection count low (24 documents per day per app), and store the data in a way that can be further rolled up using the aggregation framework. The increment operations will also be fast because we can expect the document to be in the working set every time we want to $inc it. However, you probably would not ever look at a single hour by itself, but rather in the context of a day. With that in mind, MongoDB’s data modeling principles lead us to look to embedding documents and having a single document by day. The revised schema is:

app_id: App identifier,
date: Date of the document,
total_opens: Total number of opens this day,
0: Number of opens at midnight,
1: Number of opens at 1am,

23: Number of opens at 11pm

Now, when an app open occurs, you upsert the document based on the {app_id, date} tuple to $inc the total opens and the hour. With one document per day, pulling the distribution of app opens per day is extremely easy, and even pulling it for a month means only looking at most 31 documents! Keeping the total opens per day on the document makes it easy to aggregate open counts across longer spans of time.

This works all well and good, but what about when we want to show app opens over time based on some dimension? Or compare how iPods are doing against iPhones? Here is where we can use MongoDB’s flexible schema and embedded documents to track hourly data. Say we want to track the number of app opens by device type (iPad Air, iPhone 4, iPhone 5S, iPod Touch, etc.). Since we don’t have to declare fields ahead of time with MongoDB, our application layer can programmatically $inc fields based on the values in each dimension. Take a look at this schema, which can be easily generated dynamically:

app_id; App identifier,
date: Date of the document,
totals: {
app_opens: Total number of opens this day,
devices: {
"iPad Air": Total number of opens on the iPad Air,
"iPhone 4": Total number of opens on the iPhone 4,
0: {
app_opens: Number of opens at midnight,
devices: {
"iPad Air": Number of opens on the iPad Air at midnight,
"iPhone 4": Number of opens on the iPhone 4 at midnight,


This schema is easily extensible if you want to add other dimensions. Appboy uses similar schemas in certain places in our product. Though, to be clear, pre-aggregated analytics are great for a fast lookup of series data, but be sure that you store the raw data as well. Doing so allows you to perform an arbitrary analysis of your data (whereas pre-aggregated data requires that you knew the question ahead of time), and also gives you user-level attribution.
App opens are conceptually no different than some other event which happens inside the app. Therefore, you can make the schema slightly more generic and create time series data on any event. At Appboy’s scale, tracking billions of data points each month, that means making many billions of writes each month.

We moved to ObjectRocket from another database provider because we liked the shard-first strategy they promote. Before ObjectRocket, we had been scaling up vertically as we grew, but sharding lets us add more servers horizontally as we need to accommodate more reads and writes. When working with MongoDB, I can’t recommend enough to shard from the beginning! It took us about a month of development efforts to rewrite parts of our application to support the restrictions sharding places on your application. Choosing a shard key is extremely important, and ObjectRocket jumped on the phone with us multiple times to discuss and suggest shard keys for each collection in our application.

Scaling by adding another shard, instead of vertically scaling, improves our cost-per-unit of scaling, making ObjectRocket more cost-effective and predictable from the get-go. ObjectRocket’s sharding management is simple and powerful, with a level of sophistication we couldn’t find elsewhere. And in terms of value, ObjectRocket is far better than the competitors: each shard has 2 secondary servers instead of just a secondary and an arbiter, and backups are included.

Running MongoDB with ObjectRocket gives us the performance, value and consistency our customers demand, making it a trusted choice for Appboy.

I’ll be presenting at the NYC MongoDB meetup at the eBay offices on 11/19, discussing mobile app analytics and delving deeper into Appboy’s use of MongoDB’s flexible schemas and statistical analysis on top of MongoDB. Shoot me a line at @jon_hyman or if you have any questions, or let me know how you’re using MongoDB for analytics!

Posted by & filed under Features.

ObjectRocket was built on the core premise of enabling simple and reliable scalability for MongoDB.

At it’s core, ObjectRocket utilizes MongoDB’s native scaling architecture called sharding. But it’s a cloud world, and in the cloud there are interesting things we can do when we have lots of compute at our disposal. Customers can start off small, and grow automatically. When users sign up, they instantly get a fully provisioned sharded cluster in whatever plan size they choose. All of the complicated sharding components are automatically setup, and there is zero configuration for a customer to complete. So scaling on ObjectRocket is seamless.

Here is how we do it.

At the core of the system is our automation agent called RocketScale™. This component is a back end job written in python/APScheduler. It’s job in life is to detect when a customer needs to grow, and then handles the process of adding a shard to the cluster. Each customer and instance pair gets an isolated APScheduler job queue for RocketScale to poll and analyze.

RocketScale works using some basic metadata instructions as it polls, one configurable by the customer. The setting named autoadd_shard_threshold is customer configurable, and instructs RocketScale when to add a new shard. Rocketscale polls our metadata for this threshold, then compares it to the actual disk usage of each instance. If the disk space used by the customer exceeds the threshold, a new shard is added. It’s just a simple bit of metadata as:
{autoadd_shard_threshold: 80}
This setting is a configurable in the ObjectRocket UI under instances/{instance_name}. By default new instances are set to a default 80% threshold. We recommend sharding early and often to avoid any possible issues with the MongoDB balancer, and 80% is a nice compromise of space usage and ease of scaling. Setting RocketScale to 0 or leaving it empty disables this process.

It should be noted that MongoDB won’t be able to use multiple shards unless there are shard keys defined on the major collections. ObjectRocket customers must create these keys using our UI in order to instruct MongoDB how to logically split the data. Selecting shard keys can be time consuming and tricky, and we have some tools that are coming soon to help in this process. For today, users simply specify the shard key(s) they would like using the UI at

One interesting aspect of this process is that RocketScale always has a shard at hand to instantly add because of the way we provision shards. We pre-provision shards ahead of time in various plan sizes. Adding a shard is simply grabbing the next shard in line and assigning it to a customer. This is all done in the background and is very quick to complete. ObjectRocket manages the number of candidate shards in the queue and ensuring that we have the proper capacity to add for customers as needed.

RocketScale has a couple sanity checks built into it to ensure it’s doing the correct thing. For instance:

  • Checks the version of MongoDB to ensure it matches
  • Checks to ensure we haven’t added many shards in the last few minutes (runaway sharding!)
  • Sanity checks the instance is OK and usable

When a shard is added, the ObjectRocket notification system sends a message regarding the change. The message generally has the format of:

Hi ObjectRocket User,

Your ObjectRocket instance named 'foo' is getting low on storage space. 
RocketScale (our automatic scaling engine) will be adding a shard soon 
to horizontally scale your instance, and your monthly bill will increase 

The following collections don't have any shard keys defined, and 
won't make use of this additional shard:

Even if additional shards are added, if a collection without shard keys 
uses all of the remaining storage space on your instance, you could 
experience downtime. ObjectRocket strongly recommends you define 
shard keys for all of your collections.

You can add shard keys to your collections by following these steps:

1. Browse to
2. Click on the database name containing the collection without shard keys.
3. Click on the collection name that does not have a shard key.
4, Click on the 'Shard Key' tab.
5. Click on 'Add Shard Key'.

An excellent guide to selecting shard keys can be found at .

To silence future notifications for this instance, click the link below:

If you have questions or issues, you can always ping us at:

The ObjectRocket Team

In addition, ObjectRocket support also sees a message that the customer grew so we are in the loop in case the customer has questions.

Once a new shard is added, the MongoDB balancer is kicked off to balance the chunk data onto the new shard. In some cases the customer may have selected a balancer window and thus the balancer will not fire up until the specified window starts. Managing these settings is easy with our recent Balancer ease of use enhancements.

In addition to RocketScale there are user controllable mechanisms like the UI and the API where a shard can be added, but we will save those items for next time.