I have customers that would like the ability to retain annual snapshots going back 5 or so years for compliance reasons. Currently, you can do this with monthly snapshots by retaining for 5*12 months, but then you have to store all the monthly snapshots in between.

Allow auto-scale for IOPS.

Currently we can only restore full cluster from backup like snap using GUI interface. If we want to restore one or more specific db, it needs manual dump and restore from backup. if we have an option to restore specific db to cluster through GUI interface, it will be very useful.

The email Alerts that MongoDB provide are very useful, especially the Oplog and CPU Usage. However, the subject of the emails are not clear and does not specify the Alert type. It is just a generic "Alert". It would be great if MongoDB can add "Alert Oplog" or "Alert CPU Usage" to the email subjects to make them much more clear and helpful. Thanks!

there are really 3 steps for our dev teams to get moving in Atlas:
1. create an org
2. create a project
3. create a cluster
the first one is the only one that still has to be done from a console. if we had a terraform script to create an org in our account, we could trigger creation after approval in ServiceNow

Achieve feature parity with AWS IAM cluster authentication support.

There should be an option to schedule scale up/down or suspending/resuming at specified time & day.

For example, DEV environments could be auto-suspended at 6pm and resume at 8am on weekdays, and be suspended all weekend.

Production clusters could be scaled down e.g. from M80->M60 every evening and on weekends rather than being suspended completely.

This would help save money but would need to be coordinated with the existing auto-scaling based on load.

This would need to be at the cluster level since sometimes different clusters in a single project could have different workload patterns.

Since Atlas clusters now support different sets of hostnames, it would be good to explore the feasibility of allowing users to add their own hostnames to the cluster configuration and TLS certificates such that custom connection strings can be used.

One use case for this is being able to "wrap" Atlas connection strings, such that an application's connection string would never need to change despite underlying cluster changes (cluster being moved between projects, etc.)

This could also be useful if you wished to whitelabel your cluster.

The BSON spec includes support for UUID values, also known as GUID values.

The format of UUID values are defined in rfc4122.txt. For example,

f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Users would like to work with UUID/GUID values in Data Explorer as a fully supported data type, including search support in the RFC layout, ability to create new document fields of type UUID, support for UUID type _id fields and the ability to edit UUID values in existing documents.

The mongo shell documentation provides this example:

UUID("3b241101-e2bb-4255-8caf-4136c566a962")

The current "Test Failover" feature supports testing application/driver resiliency in case of elections. For additional testing, we want to be able to cause a node or nodes to be shut down and started up in a cluster. There should be selectivity allowing the entire node or just the mongod or mongos process to be shut down and started up.

If I already have Cloud Manager backups, or can take an EBS snapshot, I want to be able to quickly Live Migrate this replica set to minimize migration time and load on my existing infrastructure.

Here are some suggested functionalities
- Import and export of bulk documents.
- Quickly filter and sort the required documents. (This is achievable in Compass but not in Atlas UI)

It would be good if users are able to modify their First and Last Name after account creation.

Atlas clusters don't support the setParameter command and, as a result, users aren't able to configure log levels. I understand the reasoning behind not exposing permissions to run setParameter to DB users so, in lieu of that, it would really helpful if Atlas users were able to configure log levels through the Atlas UI, preferably at the Node or Cluster level.

Thanks!

Test environment are usually paused during the night and the weekends. Currently the only way to do that is to automatise a RestAPI call or call mongocli automatically (e.g. via crontab)
Would be nice to allow to define a time windows on which the cluster stays pause via UI

Unlike a connector (https://feedback.mongodb.com/forums/924145-atlas/suggestions/40688308-splunk-connector-for-atlas) it would be useful if Alerts could be sent to Splunk.