Production MongoDB
Atlas, Backups and Monitoring
Managed MongoDB: what Atlas takes off your plate, and what you still have to watch.
Atlas runs the replica set (or sharded cluster), OS, patches, and a lot of failover. It does not design your schema, your indexes, or your w: majority. You still own the data model, slow queries, connection count, and who can reach the cluster (Security next).
- Backups. Snapshot + point-in-time if enabled. Test a restore once; an untested backup is a story.
- Monitoring. Connections vs
maxPoolSize× processes. CPU, disk, replication lag. Query profiler / Performance Advisor suggest indexes — you stillexplainbefore you create twelve of them. - Alerts. Lag, disk 90%, connection spikes. Page on those, not on every COLLSCAN in a 20-document staging DB.
- Maintenance. Atlas rolls nodes. Majority writes and a retrying driver (
retryWrites=trueis default on Atlas URIs) are why checkout survives a brief election.
Self-hosting means you own oplog size, disk, and 3am elections. Atlas means you pay and still get paged for your query. mongodb+srv DNS seeds the set; rotate credentials without putting them in git. Search/Charts/Triggers exist — they are products, not a substitute for $text literacy or for an index on userId.
Interview question
What does MongoDB Atlas manage for you, and what do you still own?
Atlas runs replica sets or sharded clusters, patching, and a lot of failover and backup plumbing. I still own schema, indexes, write/read concern, connection pooling, and access control. I watch connections, replication lag, disk, and slow queries, and I have restored a backup at least once.