There’s a lot to be said about running a MongoDB database in the cloud. You can get server clusters online, quickly, and all the networking is managed and secure. All your users can be connected up to it and it’ll have automated backups. A service like Atlas is great for this kind of thing. But there are times when you may want to install your own local MongoDB and some good reasons to do so. So, here’s five of them:
1: Free with No Limits
A lot of cloud databases offer you a free tier. The free tier usually has some limits on it. Take MongoDB Atlas’s M0 free tier, where the limitations start with a maximum storage capacity of 512MB and include a range of restrictions because the database is on a shared platform. If you install your own MongoDB locally, your only limits are how much disk space and RAM you can spare to run your database.
2: No need to be online
It may seem obvious but a cloud database means you have to be online on the internet to connect to it. If you are traveling or working somewhere with limited connectivity this can be a problem. Worse still is if that connectivity is on a pay-as-you-go basis and the tariff is high. Every query and set of results will cost you money.
3: Zero lag
When you are running with a cloud database, the latency of the internet will also be in play meaning extra milliseconds on each and every query you make from an application. While it’s hard to spot that lag in a user driven GUI application like Studio 3T, that lag will always be there (unless they get 5G performing the way they’ve been promising… no, don’t hold your breath).
4: As fast as your local machine
Running your database locally means all your local CPU power is available for the more compute intensive tasks. Shared cloud databases have, by design, to be good neighbors to other databases running on the same hosts. So there will be reasonable limits. That or you’ll find that every now and then performance dips when someone else is running a compute intensive task. When you run locally it’s only you competing for resources.
5: Replication Free
Unless you use something like Docker and configure yourself a mini-cluster locally, your local MongoDB will be a single instance of MongoDB. That means it won’t have to replicate data to another instance of MongoDB to make it highly available. And that in turn means more resources that are free for you to consume with your applications.
So who’s this local MongoDB good for?
- Anyone doing development who doesn’t need to plug into the production systems. (Studio 3T can help give them real test data too through the use of Data Masking)
- Anyone who wants to crunch data that’s normally production critical without impacting on the production process. Studio 3T can help export that data to the local database using its export features)
- or who needs a database but is away from the Internet
- and also everyone who needs an effective free local database
But… the case against local MongoDB
Of course there are caveats to this.
- Production – MongoDB is always going to be a cluster of three machines or more running MongoDB. Running a standalone local MongoDB is great for performance but that’s all.
- Replication, Latency and Other People – if you are developing on a standalone MongoDB, don’t expect the same performance when you move your application over to running on the cloud. The production cluster will be doing replication, it will be remote and there will be latency, and if you are going to production on a shared platform, there will be other people competing for resources. It’s not a reason not to build locally, more of a reason to make sure you test in the cloud to make sure you haven’t leant on the performance button a bit too much.
- No backups – Unless you’re well organized and do back up your laptop or desktop, there’ll likely be no backup for your database. If you accidentally corrupt or delete your data, you’ll have to recreate that data.
- No features like encryption at rest and other enterprise options – Assuming that you go with MongoDB’s Community edition, you won’t be able to use the various enterprise features but, that said, most of them are operational/deployment features for big deployments.
- Security – you are responsible for it on your local machine. When you install MongoDB now, it binds to the localhost only, but watch out! If you bind to an IP address to give others access to your MongoDB, you’ve opened a can of worms – you’ll need to ensure you have users and authentication set up to manage incoming connections.
Finally
When you’ve decided to go local, you can find all the details for setting it up in the following articles:
- How to install a local MongoDB on macOS and connect to Studio 3T
- Windows 11: How to Install MongoDB with Studio 3T
Then you’ll be ready to import data and get querying, aggregating and making more of MongoDB with Studio 3T.
This article was originally written by Dj Walker-Morgan and published on Studio 3T’s blog.