Skip to content

Atlas

Share your idea. In order to help prioritize, please include the following information

  1. A brief description of what you are looking to do
  2. How you think this will help
  3. Why this matters to you

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

1258 results found

  1. SimplifiedJson format

    Kafka source connector has an output format option of SimplifiedJson which is easier to parse by the downstream applications. Mongo utilities or any of the Atlas features do not support this as an output format as of now.

    Mongo does have canonical format output for mongo export which can be matched with kafka extended json format but it requires additional translation by the 3rd party applications.

    Is there a feature in place already to have atlas $out or mongo export or dump utilities to output data in Simplified json format? If not can this be looked into?

    9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. API - Version 2

    We saw that the api version is now in v2 for some resources (as clusters) - https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/

    We tried to change some App services functions from v1 to v2, but ended resulting in some errors (or needing to add more parameters than the original one - in version 1).
    Using version 1, we only inform what we need to change ("instanceSize") plus the providerName.

    to use version 2, we need to inform all this parameters (if it's a replica-set. If it is a sharding we also need to inform the numShards):
    "replicationSpecs":[{"regionConfigs":[{"electableSpecs":{"instanceSize":"M10","nodeCount":"3"},"priority":"7","providerName":"GCP","regionName":"CENTRAL_US"}]}]}

    What I need to change is only the…

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. A new role for security auditing purposes

    Currently MongoDB Atlas provides two read only roles at project level ("Project Read Only", and " Project Data Access Read Only").

    "Project Data Access Read Only" seems to allow access to the data also, while "Project Read Only" role does not allow access to the logs. (https://www.mongodb.com/docs/atlas/reference/user-roles/)

    For security officers (internal/external), they need to access to the logs (audit, access, etc) and also to review the configuration; but don't need access to the data.

    Therefore, I would like to request a new project level role for security officers with following features.
    - access to "Download Logs"
    - access…

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. Terraform lifecycle ignore_changes tags

    It would be nice if tags would not be set of list and will be a map, like tags for Azure resources.
    In that case, you can ignore some tags by name. Like this

    lifecycle {
    ignore_changes = [
    tags["costcenter"],
    tags["environment"],
    tags["projectcode"]
    ]
    }

    https://github.com/mongodb/terraform-provider-mongodbatlas/issues/2006

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. MongoAtlas Orga - Maximum number API keys exceeded

    We have detected in our organisation that the limit of API keys has been reached. This is currently affecting our project teams in terms of resource distribution, so we are asking for an increase in the quoter in the short term.

    Problem: We can't create keys and also delete them. The problem is that the key does not have an owner. Only org owner can delete this key. They did but this is only a reference deletion.

    Alerting: Condition for alerting is not there

    What we want to achieve:
    - Transparency for the org owners about what the limit level…

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. Improved deletion protection against malicious users

    Currently, the only option of preventing malicious admin users from deleting a cluster with all its backups is to enable a backup compliance policy. However, this policy is quite the beast with complex processes and guarded by a single user account (which could then as well be the malicious one).

    It would be good to have some less impactful way of protection against malicious users.

    For example, when deleting a project in Google Cloud, an email is sent to all project owners and the project including all of its data can easily be restored within a period of 30 days.…

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Autoscaling with custom conditions to scale up( change 1 hour to adjustable time) or down(change fixed 24 hours to adjustable time)

    Currently autoscaling is predefined with conditions like
    scale up:
    The Average CPU Utilization has exceeded 75% for the past hour.
    The Memory Utilization has exceeded 75% for the past hour.
    scale down:
    The average CPU Utilization and Memory Utilization over the past 24 hours is below 50%.
    The cluster hasn't been scaled down (manually or automatically) in the past 24 hours.

    Following changes will save more resources and money:

    -This 24 hours time for scale down should be made flexible/adjustable to suit customers requirement.
    -One hour time to scale up should be adjustable to scale up faster. This may need…

    138 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Autoscaling  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Within Atlas, create service to allow project owners to schedule shutdown/start up times of cluster to reduce hosting costs

    Request to provide an enhancement to the Atlas service to allow project owners to schedule shutdown/start up times of clusters(or databases) and provide some notification of a successful shutdown and startup. This should be a feature with the Atlas UI and API.

    This will allow teams that have non-critical environments to effectively "turn off" and freeze the state of a cluster in order to reduce hosting cost during off hours. This can provide a better value proposition for existing customers and a selling point for new customers, without having to introduce a third party tool that requires additional configuration and/or…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Need Prior notification For The Scheduled maintenance

    We have noticed that our servers undergo scheduled maintenance, resulting in unexpected reboots. However, we lack information about the nature and purpose of these maintenance activities. We require a prior notification regarding scheduled minor/major maintenance to ensure that we can take proactive measures from our end. This would enable us to prepare appropriately and minimize any potential disruptions or issues caused by the maintenance.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Alerts  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. 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…

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. Support for push-based logging integration with Google Cloud Storage

    As of now, MongoDB Atlas supports log export functionality exclusively with AWS S3. In addition to the existing AWS S3 bucket integration, would be good to have the capability of pushing logs to GCP Cloud Storage for organisations who depend on GCP for cloud infrastructure.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. Push Atlas org events and projects to S3

    Similar to cluster logs being pushed to s3 feature, if a feature to push organization, project and cluster events to s3, our event ingestion pipelines could be simplified significantly. Without the feature we are forced spin up event ingestion agents and make them reliable/available. These ingestion agents source the events via API and publish them to cloud watch logs, that are eventually fed into our observability stack. If the events can be pushed into s3, we can eliminate multiple intermediate components.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. Backup Compliance Policy to enforce "Snapshot Distribution"

    Backup Compliance policy currently can help with protecting snapshots in other regions using "Keep all snapshots when removing additional snapshot regions" option to prevent users from deleting backups copied to other regions. However we do not have a way to enforce that snapshot backups are copied to all regions where a primary could be elected.

    In order to achieve faster RTO having backup snapshots in all regions where a primary can be elected is important. Hence the feature to enforce copying backup snapshots and oplog backups to other regions via backup compliance policy is very important to compliance mandates and…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. Atlas DNS name more than 23 characters from the cluster name.

    Allow users to have longer DNS name from the cluster name. Currently, Atlas cuts the first 23 characters from the cluster name and the users can't check the cluster name inside the mongo shell.

    Example:

    Cluster name longer than 23 characters : xxxx-us-east-1-multi-use-1
    DNS name : xxxx-us-east-1-multi-us.xsj8t.mongodb.net

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. "Deviation from Norm" and "Frog Boil" type alerting

    Currently Atlas only alerts us when CPU reaches a critical threshold such as 90%. We would like to see additional types of alerts to detect issues sooner, including the following.

    1. “Deviation from norm” - A given metric is X% worse than the Y-hour average at the same time window for the past Z days (e.g. “CPU today at 4am is much worse than the average of 3am ~ 4am for the past 7 days”.)
    2. “Frog boils” - A given metric is becoming progressively X% worse over Y hours / days / weeks (e.g. "CPU usage is 10% higher on average…
    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. Enable Atlas Maintenance Notification without specifying a maintence window

    There should be an option to enable Alert notification for Atlas maintenence without specifying an Alert Window. Just because a specific window is not required, MongoDB Atlas should allow an option to receive notification that one occurred. This would save time hunting down root cause for restart events and allow customers to be notified when a change occurs in their cluster.

    8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. 11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. (RBAC) Remove CREATE_COLLECTION grant from INSERT permission

    In according to the least privilege principle we would like to have a better granularity when defining roles. This feature would help us to have uncontrolled collection creations by applications

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Atlas metrics granularity after 48 hours

    For metrics older than 48 hours, the data is presented in 1-hour intervals. This level of granularity is often too coarse for a thorough examination of past events and trends. Such a broad view can obscure smaller yet significant details critical for understanding and resolving performance issues that occurred in the past.

    Suggested Improvement:

    having a smaller granularity value for historical metrics beyond the 48-hour timeframe. Providing data in smaller intervals would greatly enhance our ability to conduct in-depth analyses and diagnose past performance issues accurately. This would be particularly beneficial for conducting detailed investigations of historical data and identifying…

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. Use cluster id as app_id when creating a trigger via terraform

    We would like to specify the cluster id as appid inside the mongodbatlasevent_trigger resources in order to match the trigger creation available via gui

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?

Feedback and Knowledge Base