Please release a dark mode MongoDB Atlas interface. Thank you.

It would be great if I could connect to and run commands against my cluster via the Atlas UI so I don't have to rely on downloading and running the shell locally.

I'd also be more confident I was running commands against the right cluster as I would have less reliance on managing connection strings and differentiating between them. This would be helpful if I'm not on my regular machine and need to do some ad-hoc querying or debugging.

There's no way to stream logs from MongoDB on Atlas right now. I should be able to stream logs, either to Datadog or Cloudwatch or something!

Right now, there's a "test failover" option, which shuts down the primary and forces an election. However, the option is only available if the cluster is in a healthy state.

If, for whatever reason, the cluster is unhealthy, it's impossible to manually restart the primary. It should be possible to force an election in an unhealthy state. Often, this is all that is required to get back into a healthy state (e.g. if the primary is in a CPU burning loop that was caused by an unexpected write pattern that has stopped.)

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.

Hi.
We would like to have the possibility to administrate user rights also for the Billing area. In order to restrict all users seeing the invoices and to give this right only to particular people who are directly responsible for it. Please consider such feature for the next releases.

Alerts are often very cryptic & don't provide any useful information. For example, when alerting that queries are returning too many rows, without informing me the query or at least the collection, that's very useless. I'm looking at a replication oplog window alert right now and I have no idea what to do about it.

The current "Test Failover" feature supports testing application/driver resiliency in case of elections. For additional testing, we want to be able to cause a node or nodes to be shut down and started up in a cluster. There should be selectivity allowing the entire node or just the mongod or mongos process to be shut down and started up.

Allow the "SET GLOBAL mongodbmaxvarcharlength = n" to be permanent after a Mongosqld restart. Currently, the setting is ephmeral and must be set everytime the mongosqld daemon is restarted. Currently, our production environment mongosqld can restart without our knowledge at anytime. This results in the mongodbmaxvarharlength variable being reset to zero, which can lead to a production outage. Is there anyway this can be automated, maybe through database trigger?

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.

mLab had the option to create a single-node deployment, which was very nice for development environments where redundancy isn't important, but keeping costs down is.

Would be nice to see this in Atlas as well.

Datadog recommends having only one account and feed data from all environments into it, and then it’s important to tell them apart by using tags.

Please add the ability to set tags in the Datadog integration configuration, e.g. env:production

I'm trying to get logs from MongoDB Atlas to Splunk, and there's currently no native interface to do it, so instead of streaming to Splunk directly, I'm having to execute https calls in intervals, unzip them and then ship them to Splunk. Many products have interfaces to stream to Splunk directly, and it would certainly be handy in this situation.

Whenever Atlas wants to do maintenance, it is sending email alert about the timing of maintenance. In addition to that we are requesting information about the nature of maintenance also like Mongo patching , BI connector upgrade or increasing no of connections etc. This will give us the information about the work and we can broadcast the same to our counterparts so that they can also use the product efficiently.

Customers often want centralized permissioning for the database and LDAP is not generally supported well in the cloud. If a customer is using Azure, they want us to support Azure AD for database authentication. I believe that means using service principals

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

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.

The Restrict MongoDB Production Support Employee Access to Atlas Backend Infrastructure is currently set on the organizational level. This should also be possible at the project level. Secondly, add the possibility to grant access indefinitely until revoked.

It could be incredibly helpful if we had a way to set a schedule to pause any given cluster as well as a schedule to un-pause it. This would help with cost savings and would allow to shutdown development clusters on weekends, after hours and holidays.