Compacting of a collection directly from the MongoDB Atlas website UI.

No need to run CLI commands and changing primary database.

Making regular maintenance easier.

When entering the txt value for validation atlas should use its own subdomain for the verification rather than requiring the domain root which is often populated with spf keys.

Other examples of this implementation are

Github: github-challenge-org.domain.com
Mandrill: mandrill.domainkey.domain.com
Google: google._domainkey.domain.com

Instead of forcing use of the API, why not display the MongoDB Network Peering Container ID for the peering connection in use?

Hello team,

Would it be possible to be able to set up governance rules at the organization level in order to control certain configuration elements.

For example:
Control authorized providers and regions for an organization to prevent creation of cluster in unauthorized regions. (We must keep the data in Canada for some of our databases)

Check the allowed IP (IP Access List) addresses

Disable the use of SCRAMS accounts for database access.

Control the "Data Explorer" functionality at the organization level to prevent its activation at the project level.

Hello team,

Would it be possible to have a feature to redirect activity logs from ATLAS to a MongoDB cluster.

The idea is to be able to easily retrieve these logs with Kafka Connect and also to be able to easily query in these logs.

One could configure the redirection of activities at the organization and projects level by providing the Atlas cluster to use and the access accounts.

Example:
Main organization
- Project: "Activity Feed"
- - Cluster: "Activity Feed Cluster"
- - DB: "Atlas Activities by organization"
- - - Collection: "Activities by project"

Currently the Atlas UI only presents options for how many shards a cluster can have.

Putting in a suggestion to perhaps allow similar functionality / features to Cloud Manager's shard management as shown : https://docs.cloudmanager.mongodb.com/tutorial/manage-data-sharding/#manage-sharded-collections

Currently a project is created with a set of default alerts. We need to customize these but we can only add new alerts via terraform. It would be helpful if there was a boolean flag in the mongodbatlas_project resource to disable default alert creation

It would be great if Atlas provided support for hidden, priority 0 delayed replicas. For workloads that do not need real time data or situations where data recovery is needed, a delayed replica would be the fastest way to mitigate both of those scenarios.

Currently there is no way of managing an online archive besides nuking the entire collection. This means that the collection can only grow, so costs will continue to climb.

The TTL index can already be used to automatically delete documents from your database. If this could be expanded to also delete files which have been archived, there is an easy and built-in way of maintaining an archive in size.

Right now it is difficult to rename and move databases and collections without downloading and re-uploading them.

Please enable this critical functionality as it's very common to need this when administering data.

The backup archives can be very large, and if my download is interrupted, without Accept-Range, it is not resumable. A length header is also missing, so the downloader doesn't know the size of the archive.

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

Please add support for the newly announced and already generally available AWS EBS feature. [1]

The top capability is: "The new gp3 volumes deliver a baseline performance of 3,000 IOPS and 125 MB/s at any volume size. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MB/s for an additional fee." [2]

That basically means decoupling storage performance from storage size.
It would eliminate all our IOPS pain as 3000k is more than enough for our usecase. Currently, we are slightly overprovisioning storage size in order to guarantee minimal IOPS performance.

[1] https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-new-amazon-ebs-general-purpose-volumes-gp3/
[2] https://aws.amazon.com/ebs/general-purpose/

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

The Users view in the Access Manager really needs a way to either sort or filter by role, so I can see a single screen with just the users who are Owners, for example.

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.