When a shared cluster has reached it's limit and the cluster is throttled, an email should be sent to each db-owner affected. This would save your customers AND your support a lot of time troubleshooting.

Right now there is no way for a db-owner to see this information, let alone get that information, except for asking support for help.

To effectively use Workload Isolation, it is desirable to have different indexes on the operational cluster nodes than the indexes used to support analytics and reporting query patterns. It would be powerful for Atlas to enable different indexes on Analytics nodes.

We need a way to easily ingest logs into Splunk. It needs to be all logs - node and web portal activity. Ideally a Splunk connector would be provided but a stop-gap measure would be the ability to configure Atlas to write all logs to an Azure storage account.

Lack of native log ingestion ability may be an Atlas deal killer for us.

An option to protect the "Pause" action on clusters with 2FA would help to reduce the chance of accidental pausing of production systems.

Hey there,

I know it's hard for big companies to get along, but I'd love to have a seamless experience for using MongoDB alongside DO's new PaaS offering. Can you all strike a deal please?

We are currently looking for a solution to secure our Atlas backups.

Something similar to AWS Glacier Vault Lock [1] or a simple grace period before backups are deleted once and for all would be nice.

It would be amazing to protect the Atlas backups from being deleted.
Currently, if one of our Atlas admins was compromised, the damage for the company would be enormously high. So we need to implement measures against the final deletion of our most mission critical data.

also mentioned in: [2]

[1] https://aws.amazon.com/de/blogs/security/amazon-glacier-introduces-vault-lock/
[2] https://developer.mongodb.com/community/forums/t/is-there-a-vault-lock-for-atlas-backups/11041

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.

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.

To speed up recovery after restoring from a snapshot or having a node replaced, it would be nice to have the option to use AWS Fast Snapshot Restore

https://aws.amazon.com/blogs/aws/new-amazon-ebs-fast-snapshot-restore-fsr/

This would allow the disk to have full performance as soon as available.

As described in https://docs.mongodb.com/manual/tutorial/configure-a-hidden-replica-set-member/, on-prem mongodb deployments allow to configure a hidden replica set members which are good for workloads with different usage patterns from the other members in the replica set. It would be useful to have similar functionality for Atlas replica sets.
In fact, to elaborate, being able to configure an on-prem hidden replica set member for an Atlas replicaset will help in meeting regulatory requirements where organisations are required to host a near real time mirror of data on on-premises.

It could be very interresting to be able to setup the retention of the events by organisation, projets and clusters. Actually I understand that this value is 30 days. So it to short for us, so we need to download the activities logs and it difficult to seach in files after that.

Events (in the perimeter: organization, projects, cluster) are useful for monitoring activities. But it would be very useful to be able to set the alarm on these events. The goal is to be informed when certain actions occur.

The best is to be able to have a configuration control policy. Especially to control security, network configuration, etc ...

For example:
- Be able to avoid the use of user scram.
- Be able to avoid using unauthorized IP addresses
- Be able to avoid changing the configuration of access to database data (DataExplorer) from the Atlas portal

When performing a forensic analysis for the purposes of a restore, in order to determine the appropriate point in time when our data was last "sane", it would be awesome if we could start with a point-in-time restoration, and play the journal forward, e.g. performing a bisect on the data.

Right now, I do this manually. Would be good to see the totals prominently, along with a recommended upgrade/ not next to it, and single click to select the next size.

Hi,

We'd like to have the ability to remove documents from an Online Archive. Mainly based on a date, but possibly other criteria.

Thanks!

Allow to create a backup when we want, on every type of cluster (like we could do with mLab plans)