Right now Mongo Atlas allows you to assign two types of roles to all the users: Organization and Project, and for each set it gives you some predefined roles.

The problem with this is you can't have any kind of granular control of what permission is assigned to each user. (e.g. to allow a user to create a trigger through Mongo Stitch it needs the Project Owner role).

This is a major setback as I'm giving my coworkers more access than needed.

A good solution would be to have something like the database access control in this part so we can create our own custom roles to assign to he users.

Hi, we have tried BETA of Autoscaling feature and we have some thoughts how to make it better. In its current setup its not really suitable for our production workloads. Here are some thoughts how to make it better:

1. Define separate scaling steps At them moment the scaling step is always 1. Going from M10 -> M20 which is not really suitable for burst loads where going one step up might not be enough. Same goes for rapid scaling down

Example:
Scale range = M10 - M50
Scale step up 4 = (M10 -> M50)
Scale step down 2 = (M50 -> M30 -> M10)

1. Define custom timescale
   It seems that current setup is to start scaling down after 72h, and then repeat every 24h.
   Our system can be scaled down much more rapidly, when our burst load goes away its done for a few days, we know we can start scaling down after 12h and repeat every 6h.
   With current setup it will take 6 days to scale down from M50 -> M10.

2. Define custom scaling metrics and thresholds
   It seems that current system is not taking N of connected clients as a scaling metric.

3. when connecting from cloud functions its easy to have a lot of connections which are not draining CPU or memory, when we are scaled down to M10 that limit is only 200

4. additionally we would like to scale up when our CPU limit is >50% which is not possible ATM

Nice to have:
4. Time based scaling events
scale up/down at specified time & day, useful for scaling up DEV/Research environments within working hours

PS: writing a long post in this form is terrible

Today when an Atlas cluster is deleted, all backups/snapshots of this cluster are deleted along with it.

This is especially an issue when working with automation tools like terraform, where a cluster can be deleted by accident easily.

In AWS Aurora Postgres, for example, there is an option to create a "final snapshot" before deleting the cluster.

If this option is enabled for a cluster, whenever a user triggers the deletion of the cluster (either manually, via API, or any other method), a final snapshot will be created, before the cluster is deleted.

This final snapshot is then available independently of the deleted cluster, so in case of accidental deletion, we can create a new cluster based on this snapshot.

This would be a huge security and safety improvement.

It is possible to quickly delete an entire cluster, for example through terraform, if you're not careful.

It would be great to have a "Termination Protection" feature that can only be disabled in the Admin UI and not via the public APIs.

In terraform I could then enable it like so

resource "mongodbatlas_cluster" "my_cluster" {
  enable_delete_protection = true
}

When I would run terraform destroy the cluster should not be destroyed and instead the API returns an error saying that the Cluster has Termination Protection enabled. If I want to disable it, I can login to the Admin UI, select the cluster, then click "Disable Termination Protection" somewhere.

AWS has a similar feature where EC2 instances can have Termination Protection enabled. With Termination Protection enabled they cannot be deleted through code, even CloudFormation will throw an issue.

Hello,

I think it would be a good idea to have team management at project level.
We have many projects and members in our Atlas account.
I'm a organization owner. The people in my organization use the Altas service. I create
a project for them and give my colleagues the project owner authorizations.

Project owners can invite other members. This is good. But it's a little inconsistent that
they are not able to create groups or teams within their projects They have to manage the permissions for each member separately.

We can't use organization teams, because they are located at the organizational level. Therefore, only the owner of an organization can create teams.
And only the owner of an organization can add or remove members from a team.