Two practical concerns before running MongoDB with real data: how you get your data back if something goes wrong, and who is allowed to touch it in the first place.
mongodump exports an entire database (or a single collection) to a set of BSON files on disk — run from a regular terminal, not inside mongosh:
mongodump --uri="mongodb+srv://<username>:<password>@cluster0.xxxxx.mongodb.net/learningMongo" --out=./backupmongorestore --uri="mongodb+srv://<username>:<password>@cluster0.xxxxx.mongodb.net/" ./backupMongoDB Atlas also offers automated, scheduled backups on paid tiers — for a learning project, running mongodump manually before any risky change is enough.
Every serious MongoDB deployment requires a username and password to connect — the connection string used throughout this course already includes both. Never leave a production database reachable with no authentication at all.
Atlas (and self-managed MongoDB) supports assigning specific roles to each database user, rather than giving every user full access:
| Role | Can do |
|---|---|
| read | Read data only, in one database |
| readWrite | Read and write data, in one database |
| dbAdmin | Manage indexes and schema, no data access |
| atlasAdmin / root | Full administrative control — reserve for a small number of trusted accounts |
Give application users the minimum role they need
An application's connection string should use a user with only the roles that application actually needs — usually readWrite on its own database, never a full admin account. This limits the damage if that connection string is ever leaked.