Keeping Your Costs Down with MongoDB Atlas Serverless Instances
Rate this article
The new 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 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 . 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!
If you want more information on how to appropriately index your data, there are a bunch of good resources to check out. MongoDB University has a free course, . It'll teach you the ins and outs of analyzing your queries and how they make use of indexes, and things to think about when indexing your data.
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.
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 "" 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.