Keeping Your Costs Down With MongoDB Atlas Serverless Instances
Rate this article
The new MongoDB Atlas serverless instance types are pretty great, especially if you're running intermittent workloads, such as in production scenarios where the load is periodic and spiky (I used to work for a big sports website that was quiet unless a game was starting) or on test and integration infrastructure where you're not running your application all the time.
The pricing for serverless instances is actually pretty straightforward: You pay for what you use. Unlike traditional MongoDB Atlas Clusters where you provision a set of servers on a tier that specifies the performance of the cluster, and pay for that tier unless your instance is scaled up or down, with Atlas serverless instances, you pay for the exact queries that you run, and the instance will automatically be scaled up or down as your usage scales up or down.
Being able to efficiently query your data is important for scaling your website and keeping your costs low in any situation. It's just more visible when you are billed per query. Learning these skills will both save you money and take your MongoDB skills to the next level.
I'm not going to go into any detail here on what an RPU is, or exactly how billing is calculated, because my colleague Vishal has already written MongoDB Serverless: Billing 101. I recommend checking that out first, just to see how Vishal demonstrates the significant impact having the right index can have on the cost of your queries!
The MongoDB Manual also contains excellent documentation on MongoDB Indexes. You'll want to read it and keep it bookmarked for future reference. It's also worth reading up on how to analyze your queries and try to reduce index scans and collection scans as much as possible.
If you index your data correctly, you'll dramatically reduce your serverless costs by reducing the number of documents that need to be scanned to find the data you're accessing and updating.
Once you've ensured that you know how to efficiently index your data, the next step is to make sure that your schema is designed to be as efficient as possible.
For example, if you've migrated your schema directly from a relational database, you might have lots of collections containing shallow documents, and you may be using joins to re-combine this data when you're accessing the data. This isn't an efficient way to use MongoDB. For one thing, if you're doing this, you'll want to internalize our mantra, "data that is accessed together should be stored together."
Make use of MongoDB's rich document model to ensure that data can be accessed in a single read operation where possible. In most situations where reads are higher than writes, duplicating data across multiple documents will be much more performant and thus cheaper than storing the data normalized in a separate collection and using the $lookup aggregation stage to query it.
The MongoDB blog has a series of posts describing MongoDB Design Patterns, and many of them will help you to model your data in a more efficient manner. I recommend these posts in almost every blog post and talk that I do, so it's definitely worth your time getting to know them.
Once again, the MongoDB Manual contains information about data modeling, and we also have a MongoDB University course, MongoDB Data Modeling Path. If you really want to store your data efficiently in MongoDB, you should check them out.
MongoDB Atlas also offers built-in tools that monitor your usage of queries and indexes in production. From time to time, it's a good idea to log into the MongoDB Atlas web interface, hit "Browse Collections," and then click the "Performance Advisor" tab to check if we've identified indexes you could create (or drop).
It's worth keeping an eye on your serverless instance usage in case a new deployment dramatically spikes your usage of RPUs and WPUs. You can set these up in your Atlas Project Alerts screen.
If there's an overall message in this post, it's that efficient modeling and indexing of your data should be your primary focus if you're looking to use MongoDB Atlas serverless instances to keep your costs low. The great thing is that these are skills you probably already have! Or at least, if you need to learn it, then the skills are transferable to any MongoDB database you might work on in the future.