Add a new Admin API to Atlas: Get all databases from one cluster

The profiler page shows a list of queries with metadata about them. It would be great to have the option to "explain" any query from this view, or in the slide-out view after clicking on a query.

This sort of exists in another request (https://feedback.mongodb.com/forums/924145-atlas/suggestions/44280954-create-organization-using-api-or-terraform-in-atla), but it may be buried because it's not super clear in the request name.

Basically, let us programmatically create Orgs via API.

For context, we're hoping to use this to let us automatically generate/scaffold up all of the infrastructure needed to "self-deploy" a full stack serverless application for clients. We don't want to do passthrough billing, and we want to keep client environments completely separated. Being able to spin up via API is critical for this to go smoothly.

in the settings=>additional settings=>More Configuration Options=>Set Oplog Size
show the reason why you can't increase this parameter (let's say you have insufficient free space etc.)

When we create new CKM key with new role and update credentials on project level, Atlas validates that new role can read new key. But it does not validate if new role can read existing CKM key.

When Atlas starts re-encrypting existing cluster, first node goes down but can't be started because new role can't read old key. There is no way to restore/rollback this change unless raise a ticket for MongoDB support.

Suggestion: when we upgrade credentials/role/KMS key in UI, Atlas should validate if it can finish this change BEFORE applying changes to nodes.

Currently, we have to use the UI to get a pricing estimate for a cluster. Having a programmatic way to get this estimate would be very valuable.

Currently MongoDB 6.0.1 is only available in dedicated clusters (M10+) and in serverless clusters.

We need to use MongoDB 6.0.1 or higher in the shared cluster (M0/M2/M5).

I understand that this should be in the roadmap anyway, but getting it sooner than later would be great.

Support SCIM for SSO as this can allow for more fine grained control for access groups in Atlas. This can help IT groups hit their goal of a consistent RBAC set up and improve the user experience for MongoDB Atlas users (less back and forth with IT).

https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management

Please make Atlas available in AWS's Beijing/Ningxia regions. This is important to due to China's internet restrictions to achieve the best possible performance/latency for our Mainland China customers.

Instead of completely removing a Mongo database user, its better if there is option to disable user so that if there is any untoward incident we can enable it back. After observing for some time, we can delete/disable the user based on organization requirements. Its useful in some cases like mongo db user returned to same department after some time .

Currently Global Clusters require a location field for zone targeting. Could the user get an option to be auto-detected based on the incoming connection? The reason for this is, not all app services have the ability to include location, so would be good to auto-detect it.

Give Atlas users the ability to increase the number of clusters they can create in a single project above the 25 cluster limit without having to file a support ticket.

Support NVMe disk for MongoDB Atlas Azure.

In a multi tenant architecture, the isolation of a tenant on a specific shard (when database sharding is involved) is expected. At this time, the ability to choose a Primary shard for newly created database would come in handy

It would be really useful to create a new cluster based on an existing configuration.

Snapshots are supposed to be loaded into clusters of the same configuration, but having to set up the configuration manually is prone to human error. Having an option to copy the cluster configuration would be helpful.

Support suggested the following workarounds, but the option should really exist in the UX, given that snapshots can be taken and loaded in the UX.
- use the API to create all clusters so that the config exists in code
- use terraform to create clusters

Allow generation of multiple application-specific connection strings/URIs to the same Atlas cluster. This would ease migration of databases to different clusters over time; consolidating smaller databases to lower costs, or separating busier databases to isolate performance impact.

Multiple connection strings will allow us to redirect connections seamlessly when migrating databases without requiring developers to re-deploy changes to application connection strings, minimizing downtime and coordination.

When using the "Browse Collection" feature from the Atlas Web frontend it would be nice to be able to download/view files stored in GridFS. Tools like "Studio3T" or "NoSQLBooster for MongoDB" support that use case.