In Performance Advisor, I can see sample queries for each index suggestion.
They are formatted "nicely" for human viewing, but to actually investigate it, one would want to copy it as valid mongodb json, and run it with explain or analyze it in compass, or even just run it in a console to see how long it runs before and after the index addition.
However, there is no way of doing that, and I have multiple times "translated" the good looking ui to a mongo query so I could run it elsewhere.
This is a tedious and annoying thing (especially when you need to handle dates....).
Since you already have the data but chose to display/format it in a "nice" way, you also have the json behind it so please just let me copy it as json (with the proper ObjectId and ISODate or new Date() around ids and dates.

Thank you.

It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.

Currently, Atlas has a 15 minute interval where it checks access to remotely stored Customer Managed Encryption keys for the custom encryption at rest feature.

This value is not changeable, and it implies a problem: access to encryption keys can be lost for longer periods than 15 minutes without that implying that the key has been invalidated by the customer.

A perfect example of this was the recent Azure AD global outage that prevented all authentication to the Azure platform for about 3 hours (complete outage description: https://app.azure.com/h/SM79-F88/691d78). While the key used for one of our clusters was not invalidated nor the credentials rotated, the whole cluster went down just because the auth mechanism was failing. This impacted our customers and would have easily been mitigated if the time interval for key access checking would have been longer.

There are use-cases where certain users or client IPs need to be given access restricted to only the Analytics node(s) . While it is possible to grant such users read-only permissions at the database/collection level, and have them use the ANALYTICS replica set tag in their connection string URI, it might still be possible for those users to connect to a Primary or a Secondary node (when not using the Analytics replica set tag) and run their query there.

Therefore, a feature that will either restrict specific users access to only the Analytics node(s) or a functionality that will restrict access from certain client IPs to only the Analytics node(s), will help in such use-cases.

We use AWS CDK to deploy our infrastructure. Currently there is only a Terraform provider available to automate the MongoDB Atlas deployment. We would like to have such a provider also for AWS CDK.

In a first step this provider should support:
- mongodbatlascluster create, edit and delete clusters
- mongodbatlasdatabaseUser create and remove users

Later full feature set like in Terraform should be supported.

Currently we use a self written provider. But this has hundreds of lines of code and means a lot of maintenance effort. For our teams this additional effort can be a reason to favor AWS DocumentDB/DynamoDB over MongoDB.

Hi MongoDB team,

as the organization owner I don't want that my organizational members (developers, project owners etc.) have access to the billing section. Currently every member (independent on the granted rights) has the rights to see the complete billing section and can see the whole invoice incl. the names of the projects. This isn't acceptable regarding compliance because we are working together with external companies and their colleagues shouldn't have the ability to see all invoices.

Please make the billing section of MongoDB Atlas available to handle multitenancy - so that only the organization owner can see the billing section with all invoices. It would be perfect if you could also add the posibility for the project owner to see their invoices only (and not the ones from the whole organization).

I have also created a ticket for this problem: case 00716265.

Thank you so much!

Have a nice day
Christian