Please could you extend the modify cluster API so that when an M20+ cluster is downsized to the next smaller size, the API command executes a sanity check to see if the smaller size has sufficient resources?

Return a 40x if the smaller size has insufficient resources.

Many user have Production systems that don't need huge resources over night so smaller machine size is sufficient

The cloud atlas frontend is very buggy, and not usable at all, even with a fast connection takes minutes to load a page on click.

https://cloud.mongodb.com/

I think we are loading all the components and required data from server side.
Instead we can simply load the core components, and show a user friendly spinner, that will stop spinning once content is loaded via an XHR request. This would be so much more user friendly, just showing them a spinner (maybe estimated time as well).

Currently the page stays blank white, which is terrible UX.

To avoid use of terminology that for some will have racial connotations remove the term "whitelist" from the Atlas UI.

I did a live migration from mLab to Atlas quite recently. Although, the steps for migration were simple and easy to execute it took me alot of time to get over the fear of migrating without losing any data. A tutorial video of the entire process would have calmed my nerves and helped me take a lot less time in the process.

When connecting to a Atlas cluster and selecting to connect via a Application you can select to connect with what "Driver" where you can select "Python".

For new users, they might think that the Python library (https://www.python.org/doc/versions/) is what is being referenced when in reality Atlas is referring to the PyMongo Driver.

For clarity, alter the UI from "Python" to "PyMongo" or "Python (PyMongo)" or something similar to differentiate between Python and PyMongo.

We're using Atlas to store PII (HIPAA), and we need to store the log files for an extended period of time, but we don't want any PII / HIPAA data to be stored in the logs.

a faster mongodb compass installation that is taking forever to do so.

Atlas replica set members are pre-configured with tag sets: https://docs.atlas.mongodb.com/reference/replica-set-tags/

There's no way to see what the tags are set to via the UI. It would be helpful to see this information.

The Stitch confirmation and reset password emails for the Email/Password Provider are now only in English.

A page where you could translate these emails, would be very useful.

Now we must use the function method, which is more work. I suspect a lot of people would want this feature (all non English markets).

I wish they could provide the arn service with lambda.

Similar to how it's possible to select the preferred region in a multi-region cluster, it would be beneficial being able to select the preferred availability zone in a single-region cluster. This would allow an application to live as close to the cluster's PRIMARY node as is possible.

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

when creating a private link, the resulted dns for the cluster is in the form of "cluster-pl-.{somerandomstring}.mongodb.net"
the only difference from the public endpoint is the 'pl' addition in the first section.

in order to configure the vpn wildcards and rules,
it can be extremely helpful to have this separation more general, for example
cluster.{randomstring}.pl.mongodb.net -- private links
cluster.{randomstring}.mongodb.net -- public

that way we can use the wild card *.pl.mongodb.net to differentiate and route the traffic accordingly

allow multiple Atlas CIDR (VPC Region) in the same project and allow attaching each cluster to the desired vpc.

today in order to have multiple vpcs in atlas (for example dev &prod)
they need to be separated projects, that create a lot of duplicated work and settings

In addition to AWS, Azure and GC, give an option to host on DigitalOcean. DigitalOcean has a really cheap and well-made Kubernetes system that requires VPC because container IPs are always changing, and I would want them to connect to Atlas without having to just open Atlas to whitelist every IP.

Mongomirror allows you to migrate particular databases or collections using the --includeDB and --includeNamespace parameters:

https://docs.atlas.mongodb.com/reference/mongomirror/#cmdoption-includedb
https://docs.atlas.mongodb.com/reference/mongomirror/#cmdoption-includenamespace

It would be helpful if Live Migrate allowed for use of these options as well to migrate subsets of data, instead of only migrating an entire cluster.

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.