1359 results found

1. Multitenancy of the billing section in MongoDB Atlas

   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

   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… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. LDAP Authentication: Allow Private Endpoint to the customer

   Currently, LDAP Authentication from Atlas to a customer's LDAP service can go via the Internet or via VPC peering. In lieu of VPC peering, I propose using a Private Endpoint FROM Atlas TO a customer VPC that hosts the LDAP service.

   NOTE: This would NOT be using the same Private Endpoint connection that Atlas currently supports today, which allows customers to reach their clusters privately (Customer -> Atlas).
   This would be an additional Private Endpoint in the other direction (Atlas -> Customer).

   Advantages of using Private Endpoint vs VPC peering:
   * Security: The customer VPC is not exposed to Atlas, just the LDAP service
   * Configuration: The customer won't need to verify that the Atlas VPC CIDR doesn't conflict with the customer CIDR
   * Scalability: Each Project requires a separate VPC peering connection which makes for a difficult situation with having to configure each Project VPC CIDR to be non-overlapping. In contrast, the same LDAP Private Endpoint can be shared to multiple Project VPCs.
   * Complexity: Configuring a Private Endpoint is less complex than a VPC peering connection, both for Atlas and for the customer.
   * Routing/security groups: The customer does not need to configure VPC routing, nor do they need to configure security groups to protect resources in the VPC

   In AWS, the customer LDAP service would need to be hosted as a Network Load Balancer. The good news is that NLB targets can be hosts in AWS or in a customer data center.

   Currently, LDAP Authentication from Atlas to a customer's LDAP service can go via the Internet or via VPC peering. In lieu of VPC peering, I propose using a Private Endpoint FROM Atlas TO a customer VPC that hosts the LDAP service.

   NOTE: This would NOT be using the same Private Endpoint connection that Atlas currently supports today, which allows customers to reach their clusters privately (Customer -> Atlas).
   This would be an additional Private Endpoint in the other direction (Atlas -> Customer).

   Advantages of using Private Endpoint vs VPC peering:
   * Security: The customer VPC is not exposed to Atlas,… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Allow customer encryption key validation time interval

   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.

   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… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Hosting Atlas on DigitalOcean

   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.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. As a Collections tab, aka Data Explorer, user I want to view, search for, create and update UUID and GUID field values

   The BSON spec includes support for UUID values, also known as GUID values.

   The format of UUID values are defined in rfc4122.txt. For example,

   f81d4fae-7dec-11d0-a765-00a0c91e6bf6

   Users would like to work with UUID/GUID values in Data Explorer as a fully supported data type, including search support in the RFC layout, ability to create new document fields of type UUID, support for UUID type _id fields and the ability to edit UUID values in existing documents.

   The mongo shell documentation provides this example:

   UUID("3b241101-e2bb-4255-8caf-4136c566a962")

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Explorer  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Ability to create more than one index at once

   We have migrated a huge collection with nearly 100million records into Atlas. It takes 3 hours to add indexes to it using the rollover strategy and we have tens of indexes to create.

   It would be great to simply define all indexes once before starting to apply them.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Allow Billing Alerts per Project

   Currently, we can configure Atlas to send an alert when the current bill for any project is above a specific amount. It would be great to be able to set alerts for specific projects. This way we could more easily manage budget fors projects and alert project owners.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Alerts  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Atlas - Preferences - My Date Format - allow 24hr

   We can specify date format but the time format is limited to 12hr clock. Please allow us to specify 24hr so the activity log and rest of the UI is a little easier to read. Thanks

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Add support for ephemeral password input in mongodbatlas_database_user resources

   Terraform v1.10 added ephemeral resources that are not persisted in state, and v1.11 then added support for write-only resource attributes. To make use of this new resource type, resources must take a write-only input for applicable variables.

   To make use of this in mongodbatlas_database_user, I propose adding an alternative password_wo input that is mutually exclusive with the existing password input, along with a supplementary password_wo_version value that will trigger a change if required (this is the pattern used in aws_secretsmanager_secret_version).

   The database user could then be configured as such, without the password being present in the terraform state:

   
   variable "password_version" {
     description = "Used to track changes to the password"
     type        = number
     default     = 0
   }
   
   
   ephemeral "random_password" "example" {
     length           = 16
     special          = true
     override_special = "!#$%&*()-_=+[]"
   }
   
   resource "mongodbatlas_database_user" "example" {
     username    = "example"
   
     password_wo         = ephemeral.random_password.example.result
     password_wo_version = var.password_version
     ...
   }
   

   Terraform v1.10 added ephemeral resources that are not persisted in state, and v1.11 then added support for write-only resource attributes. To make use of this new resource type, resources must take a write-only input for applicable variables.

   To make use of this in mongodbatlas_database_user, I propose adding an alternative password_wo input that is mutually exclusive with the existing password input, along with a supplementary password_wo_version value that will trigger a change if required (this is the pattern used in aws_secretsmanager_secret_version).

   The database user could then be configured as such, without the password being present in the terraform state:

   … more
   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   under review  ·  2 comments  ·  Terraform Provider  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Collection size metrics

    Hi,

    From time to time we have Atlas auto-scale up our clusters' disks. We then need to start analyzing why. In some cases it is organic growth of the data we store, but in some cases we are missing TTLs or they are misconfigured and we accumulate data we do not need.
    In both cases, trying to realize what causes the disk increase is a very tedious process as some clusters have thousands of collections.
    To overcome this, we started running a small utility that gathers some data over all our collections. It iterates on all the organizations, all the projects, all the clusters, all the databases and all the collections to collect total size, total index size, document count, etc, and then stores all this info once a day into BigQuery. We then created a simple looker dashboard over it and now it is very easy to find the collections that grow and figure out if that's OK or not.

    We think this is something that will be beneficial for more than just us. We believe this should become some service + charts dashboard Atlas should keep for each project (or better - each organization).

    We'd be happy to share more info with your product team if this seems a good idea to you.

    Thanks,
    Oren

    Hi,

    From time to time we have Atlas auto-scale up our clusters' disks. We then need to start analyzing why. In some cases it is organic growth of the data we store, but in some cases we are missing TTLs or they are misconfigured and we accumulate data we do not need.
    In both cases, trying to realize what causes the disk increase is a very tedious process as some clusters have thousands of collections.
    To overcome this, we started running a small utility that gathers some data over all our collections. It iterates on all the organizations, all the… more

    •  

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Configuring provider with shared credentials file for secrets manager

    Currently the provider allows configuration for secrets manager for the API key, however it looks like only static AWS credentials can be used which require assuming a role first and exporting environment variables. It would be much cleaner if you could support shared profiles, much like the AWS provider does https://registry.terraform.io/providers/hashicorp/aws/latest/docs#profile-1.
    https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html
    Specifically https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/internal/provider/credentials.go#L49 is static credentials, but would be great to add profile as an option as well.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Terraform Provider  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Export Aggregation Results as Metrics to Prometheus

    Add support for exporting MongoDB aggregation results as Prometheus metrics. This would allow users to track custom queries and dynamic data, enabling more granular and meaningful monitoring and alerting in Prometheus and Grafana.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. general cpu class for M400 and M600

    Currently when selecting M400 or M600 only "Low CPU" class is available. Our only option to increase CPU is going back to M300 with "General" class to get 96cpu. We would benefit a lot from "General" option of 128cpu and 160cpu.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Manage Database by Kubernetes Operator

    In our use case, we are dynamically creating feature environments based on the branch name. During this process, we are also creating MongoDB databases in the same Atlas cluster (different envs are sharing the same cluster but with different database names). For now, we need to do it with a separate CI step that should create this DB and delete it when the env is deleted.

    It would be great to have the possibility to manage DB create/delete process with Kubernetes CRD. For now it's the only 1 missing feature that is blocking us to start using Operator.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Kubernetes Operator  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    under review  ·  AdminDan (Admin, MongoDB) responded

    This is something we're considering for the future. 

    
    

    But the biggest problem we need to solve is that it's incredibly easy to create/delete/update databases within a deployment via many other interfaces. But if this happens, the Operator's source of truth (the custom resources) won't contain the changes, and the Operator would overwrite the changes using it's source of truth.

15. Atlas Webhook Integration and Custom JSON Payload

    Ability to specify a JSON body along with their Atlas Webhook's for additional functionality.

    •  

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Alerts  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Integrar la alerta de Replication lag de Atlas en el API de Prometheus

    Se solicita incluir métricas en el API de prometheus para poder implementar la alarma de Replication lag

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Support Online Archive in Azure Switzerland North region

    Please make Online Archive available in Azure's Switzerland North region

    We are using MongoDB Atlas in Azure notably to store personal health data of patients. We are based in Switzerland (which is not part of the EU), and the regulation requires that health data remains in Switzerland. We would like to use the Online Archive on Azure feature for our Atlas data but require that it is available in the Switzerland North region.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Online Archive  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. View billing information at project level

    I think it would be a good idea to be able to see billing/invoices at project level. So the project owner will only see the consumption of his projects.

    By giving project owners the "Organization Billing Viewer" role, we make it possible for them to see the billing for the whole organization. A new role for the project owner to view only their own project invoices would be nice.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Billing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Add usability to tags

    Atlas has the option to set tags to clusters. But - now what? They are just pieces of text floating around, but are completely useless.
    How about enabling to filter clusters in a project or even organization based on those tags? Split costs based on them? Query them with API calls? I have no use of those tags when they are just texts in the main page of Atlas...

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Ability to "Mass Kill" slow running queries

    Currently, Atlas has a "Kill Op" option which is useful to kill single long-running queries.

    When upgrading to MongoDB 7.0, we were faced with a situation where the Slot-Based Query Engine (SBE) was causing 1000s of queries to execute slowly, we wanted to kill them all, but it was more than a human could do by clicking "Kill Op" 1-by-1. Hence a "Mass Kill" feature which kills queries longer than X seconds (X is configurable) would have helped us greatly in an outage scenario. We ultimately rebooted our cluster to kill queries, then manually implemented a script which did this from the MongoDB console. We would need ability to do this on both primary and secondary nodes.

    Related requests:
    - https://feedback.mongodb.com/forums/924145-atlas/suggestions/43772352-killallsessionsbypattern-and-kill-sessions
    - https://feedback.mongodb.com/forums/924145-atlas/suggestions/42420421-allow-db-killop-and-manual-restarts-on-secondari

    Currently, Atlas has a "Kill Op" option which is useful to kill single long-running queries.

    When upgrading to MongoDB 7.0, we were faced with a situation where the Slot-Based Query Engine (SBE) was causing 1000s of queries to execute slowly, we wanted to kill them all, but it was more than a human could do by clicking "Kill Op" 1-by-1. Hence a "Mass Kill" feature which kills queries longer than X seconds (X is configurable) would have helped us greatly in an outage scenario. We ultimately rebooted our cluster to kill queries, then manually implemented a script which did this… more

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating