MongoDB Atlas (Cloud)

What Atlas Is, and What It Takes Off Your Plate

MongoDB Atlas is the hosted service run by the company that makes MongoDB. You do not install a server, choose a Linux distribution, configure a replica set, apply security patches or set up backups. You pick a region and a size, and a running database appears with a connection string.

It is worth being clear about what that actually saves, because "managed database" is easy to nod along to without understanding. Running MongoDB yourself in production means keeping the operating system patched, configuring authentication and TLS correctly, arranging for a second and third copy of the data so a single disk failure is not the end, testing that your backups restore, and being awake when something fails at three in the morning. Atlas does those things.

There is a permanently free tier, called M0, with 512 MB of storage. It is not a trial — it does not expire — and it is enough for every exercise in this course, for a college project, and for a small application's first users. That makes it the sensible place to learn, especially since a local single-server install cannot run transactions or change streams at all.

• Runs on AWS, Google Cloud or Azure, in a region you choose
• Free M0 tier with 512 MB of storage, no card required
• Encryption in transit and at rest, and authentication switched on by default
• Monitoring dashboards, slow-query logs and a Performance Advisor that suggests indexes
• Automated backups on the paid tiers, with point-in-time restore
• One-click scaling to a larger cluster when you outgrow the one you have

Why Even the Free Cluster Has Three Nodes

An Atlas cluster is not one server. Even on the free tier it is a replica set: three copies of your data, one of which is the primary that accepts all writes, with the others kept continuously in step as secondaries.

The reason is failure. If the primary stops responding, the remaining members hold an election, one of them becomes the new primary, and your driver reconnects to it automatically. Your application sees a pause of a few seconds rather than an outage, and no data written before the failure is lost. This is also why your connection string uses mongodb+srv:// — that form asks DNS for the current list of members instead of hardcoding one machine's address.

Replication has a second consequence that matters for this course: multi-document transactions and change streams both require a replica set, so neither works against a plain single-server install on your laptop. If a transaction example fails locally with a message about replica sets, that is why, and an Atlas free cluster is the quickest way to try it.

The Four Things You Must Configure

Setting up a cluster is quick, but four settings decide whether you can connect at all, and three of the four produce confusing failures when they are wrong.

First, the cluster itself: choose the free tier and a region physically near you or near your users, because distance is latency and latency is felt on every query. Second, a database user — created under Database Access, with its own username and password. This is not your Atlas login; it is an account that lives inside the database, and giving it readWrite on the one database your application uses is better practice than making it an administrator.

Third, Network Access. Atlas refuses connections from any IP address that is not on the allow list, so a fresh cluster rejects you until you add your own. This is the cause of nearly every "it just hangs and then times out" message from a beginner. Home connections usually get a new IP whenever the router restarts, so an entry that worked last week may need updating. Fourth, the connection string, copied from the Connect button — remember to replace the <password> placeholder, and to percent-encode any special characters in it.

# Shell
mongosh "mongodb+srv://cluster0.abcde.mongodb.net/" --username appuser

# Application connection string, kept in .env and never committed
MONGODB_URI="mongodb+srv://appuser:s3cretpass@cluster0.abcde.mongodb.net/shopDB?retryWrites=true&w=majority"

# A password containing @ : / # ? must be percent-encoded
#   p@ss:word   ->   p%40ss%3Aword

# Quick check that credentials and network access are right
mongosh "$MONGODB_URI" --eval 'db.runCommand({ ping: 1 })'

Connecting From Your Application

In code, an Atlas connection string is used exactly like a local one — the only difference is its contents. Store it in an environment variable, load it at start-up, and connect once. Every serverless and traditional hosting platform has a place to set environment variables; use it rather than a file you might commit by accident.

The database name is worth a moment's attention. If the string ends with /shopDB, that is the default database your code will use; if there is no name before the query string, the driver falls back to a database called test, and beginners regularly wonder why their data has appeared somewhere unexpected.

The parameters after the question mark are ordinary options. retryWrites=true asks the driver to retry a write once if the primary changed mid-operation, which is what makes a failover invisible. w=majority asks the server to confirm a write only after a majority of replica set members have it, so an acknowledged write survives the loss of the primary. Both are sensible defaults for application code.

// .env  (add this file to .gitignore)
// MONGODB_URI="mongodb+srv://appuser:s3cret@cluster0.abcde.mongodb.net/shopDB?retryWrites=true&w=majority"

import 'dotenv/config';
import { MongoClient } from 'mongodb';

const client = new MongoClient(process.env.MONGODB_URI);
await client.connect();

const db = client.db();              // uses shopDB from the connection string
const users = db.collection('users');
await users.insertOne({ name: 'Ananya', joined: new Date() });

// With Mongoose, the same string
// await mongoose.connect(process.env.MONGODB_URI);

Living Within the Free Tier

The free cluster is genuinely useful, but it is shared infrastructure and it has limits you should design around rather than discover during a demonstration. Storage is capped at 512 MB, processing power is shared with other tenants so timings vary, and the number of simultaneous connections is limited — which becomes a real problem if your code opens a new connection per request instead of reusing a pool.

Atlas also pauses a free cluster that has had no activity for sixty days. It is not deleted, and one click resumes it, but the first connection after a pause fails. If you are presenting a project after the holidays, wake the cluster up the day before rather than in front of the audience.

• Connect once at start-up and reuse the pool — never call connect() inside a request handler
• Keep sample data small; 512 MB includes indexes, not just documents
• Expect variable response times on shared tiers, and do not treat them as a benchmark
• Take your own mongodump backups, because automated backups are a paid feature
• Watch the Metrics tab after a load test to see which queries are actually expensive
• Read the Performance Advisor — it inspects your real slow queries and suggests indexes for them