Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Will Not Implement
Categories Atlas Backups
Created by Bathula Sai Reddy
Created on May 13, 2026

Backup Policy based on individual Database Instead of overall cluster backup

What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

We do have backup policy strategy for the cluster level within the atlas MongoDB however we need to perform the backup based on the individual database or else collection wise also if required based on the end user commitment.

What would you like to see happen?

Describe the desired outcome or enhancement.

My desired outcome should be instead of overall cluster backup we need to perform individual database and also based on demand whenever required.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

Majorly it is saving efforts and time as we don't want to perform the backup for overall cluster and also cost wise anything improvements we can see and also managing the resources.

What steps, if any, are you taking today to manage this problem?

As of now for the above problem statement we are performing locally using some basic commands like mongodump and mongorestore.


  • Admin
    Kaylee Won
    May 28, 2026

    Thank you for submitting this idea. Selective backup at the database/collection level is not on the Atlas Backups roadmap. Atlas Backups today are built on the cloud providers' volume snapshot APIs. These APIs snapshot the entire disk at a block level and don't expose any way to scope a snapshot down to a specific database or collection; the storage layer does not have that concept. Supporting selective backup in the current architecture would require moving off the volume snapshot model entirely, which is a significant re-architecture rather than an incremental feature, and it isn't something we're planning to take on, at least in the near future.

    We are, however, releasing collection and database-level restore to GA in June 2026, which lets you restore a subset of data from a full cluster snapshot without restoring the whole cluster. While this may not help with lowering backup storage costs, if you have a multi-tenant architecture where you need to roll back specific dbs/collections, this could help address that use case.