1359 results found

1. 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.

   17 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

   4 comments  ·  Integrations  ·  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. VPC flow log to identify the rejected source IP by IP access list

   Customers can identify the source IP addresses dropped by Atlas IP access list if cloud provider flow log like VPC flow log is enabled and stored in the storage like S3.

   1 vote

   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  ·  Edit…  ·  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. View cluster/storage scalable (yes/no) in "All cluster" dashboard

   Right now in the "all cluster" view, one cannot see, if the clusters are enabled for auto scaling. my idea is to add this also to avoid last minute performance alerts for non scaling enabled clusters

   1 vote

   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  ·  Edit…  ·  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. 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

   4 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

5. 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

6. Read-only access to project snapshots

   Create a role that allows less-privileged users to download project snapshots.

   Project Owner rights are currently required in order to simply download a project snapshot. Our team needs to pull snapshots in a variety of contexts, for development and offline analysis -- especially from projects associated with our non-production environments -- and we have to harass our administrators each and every time. It's frustrating to everyone involved.

   1 vote

   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  ·  Backup  ·  Edit…  ·  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. Collection query audit logs

   It would be nice to be able to see what queries were run on which collection over the last x days.

   1 vote

   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  ·  Edit…  ·  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. View Atlas user sign in method in logs or UI

   We'd like to see how are users are signing into Atlas.
   At the moment we can just see username, email and permissions.

   I want to see which Auth method they used to sign in e.g. email & password, GitHub SSO, Google SSO, AD etc.

   1 vote

   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  ·  Edit…  ·  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. Safe mode to pause non-essential changes

   I'd like to be able to put the cluster into a "Safe Mode" during an incident.

   For example, I'm responding to an incident or I suspect something's fragile or breaking, and I don't want any scheduled activities to make it worse or distract me. I also don't want to have to know what changes are scheduled, I want to pause them all regardless.

   This would pause any scheduled or non-critical changes, like upgrades, building indexes, probably resyncs, etc.

   But it would keep running cluster-safety/health-supporting mechanisms like auto-heal, and probably backups.

   And it would put up a banner on the cluster so everyone else interacting with it knows that it's in safe mode.

   I'd like to be able to put the cluster into a "Safe Mode" during an incident.

   For example, I'm responding to an incident or I suspect something's fragile or breaking, and I don't want any scheduled activities to make it worse or distract me. I also don't want to have to know what changes are scheduled, I want to pause them all regardless.

   This would pause any scheduled or non-critical changes, like upgrades, building indexes, probably resyncs, etc.

   But it would keep running cluster-safety/health-supporting mechanisms like auto-heal, and probably backups.

   And it would put up a banner on the cluster… more

   5 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  ·  Administration API  ·  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. EmbeddedDocuments Search multiple compound fields

    Today, it doesn't seem that a $search index on a list of object documents allows for an embeddedDocument search to match on multiple properties within the document.

    So, if I have:

    [{
    name: 'Doc 1',
    attached: [ { name: 'a', type: 'string' }, { name: 'b', type: 'number' }]
    },
    {
    name: 'Doc 1',
    attached: [ { name: 'a', type: 'string' }, { name: 'b', type: 'string' }]
    }]

    I would like to be able to write a compound query like this:

    [
    {
    $search: {
    index: "default",
    compound: {
    must: [
    {
    embeddedDocument: {
    path: "attached",
    operator: {
    compound: {
    must: [
    {
    text: {
    path: "attached.name",
    query:
    "b",
    },
    },
    {
    autocomplete: {
    path: "attached.type",
    query: "string",
    },
    },
    ],
    },
    },
    },
    },
    ],
    },
    },
    }]

    And for it to only find and return this:
    {
    name: 'Doc 1',
    attached: [ { name: 'a', type: 'string' }, { name: 'b', type: 'string' }]
    }

    Today, it doesn't seem that a $search index on a list of object documents allows for an embeddedDocument search to match on multiple properties within the document.

    So, if I have:

    [{
    name: 'Doc 1',
    attached: [ { name: 'a', type: 'string' }, { name: 'b', type: 'number' }]
    },
    {
    name: 'Doc 1',
    attached: [ { name: 'a', type: 'string' }, { name: 'b', type: 'string' }]
    }]

    I would like to be able to write a compound query like this:

    [
    {
    $search: {
    index: "default",
    compound: {
    must: [
    {
    embeddedDocument: {
    path: "attached",
    operator: {
    compound:… more

    1 vote

    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 API  ·  Edit…  ·  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. Request for Enabling Vendor-Metered Tagging on AWS Marketplace

    Hi Team,

    We are currently utilizing MongoDB services via the AWS Marketplace and have encountered an issue related to cost allocation tags.

    We have recently been working on improving our cost management and reporting processes within AWS.
    A key component of this effort involves leveraging AWS-generated cost allocation tags, particularly those prefixed with "aws:marketplace:isv:".
    However, upon review, we have noticed that these specific tags are not available or being applied to MongoDB services that we are using.

    The absence of vendor-metered tags for MongoDB on AWS Marketplace is hindering our ability to effectively track and allocate costs associated with your services. This capability is crucial for our organization’s internal cost management and reporting.

    Therefore, we kindly request your assistance in enabling support for vendor-metered tagging for MongoDB services on AWS Marketplace. Implementing this feature would greatly assist us in managing our AWS expenses more efficiently and accurately.

    Hi Team,

    We are currently utilizing MongoDB services via the AWS Marketplace and have encountered an issue related to cost allocation tags.

    We have recently been working on improving our cost management and reporting processes within AWS.
    A key component of this effort involves leveraging AWS-generated cost allocation tags, particularly those prefixed with "aws:marketplace:isv:".
    However, upon review, we have noticed that these specific tags are not available or being applied to MongoDB services that we are using.

    The absence of vendor-metered tags for MongoDB on AWS Marketplace is hindering our ability to effectively track and allocate costs associated with your… more

    19 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

    5 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

12. API change date format for log download

    While programming a script to download the activity feed and audit logs, we found out that the date format which is accepted for API calls does not match. While the Activity Feed is fetched with a date in the ISO 8601 format (&minDate=2024-01-24T12:30:06.415944), the audit log accepts only an epoch timestamp (...?endDate=1702632210&startDate=1702625017).

    This causes several conversion issues when automating log-fetching. To avoid these issues, we suggest changing the API call to use the same date format.

    4 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  ·  Administration API  ·  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. MongoDB Atlas historical stats by collection

    It would be helpful to have historical metrics for storage by collection. Storage space used, indexspace used, number of indexes.
    Thanks

    1 vote

    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  ·  Edit…  ·  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. Support resource tags included in billing ingestion dashboard while filtering Charts billing dashboard by resource tags

    It's important to support resource tags included in billing ingestion dashboard and filtering the charts based on these resource tags. Include the resource tags in Atlas billing dashboard as filter/group criteria

    1 vote

    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  ·  Billing  ·  Edit…  ·  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

15. Reestablish private endpoint if in status "Rejected"

    Create an AWS endpoint for connection with the (already established) MongoDB Atlas endpoint service -> AWS endpoint is in "Pending acceptance" status.
    Establish the connection with "mongodbatlasprivatelinkendpointservice" -> AWS endpoint goes into "Available" status.
    Destroy the "mongodbatlasprivatelinkendpointservice" connection -> AWS endpoint goes into "Rejected" status.
    Recreate "mongodbatlasprivatelinkendpoint_service" with the same variables -> terraform does recreate he resource, but the resource is not functional.
    In the MongoDB Atlas GUI it shows "Failed. Endpoint failed to reach available state. Click 'Edit' to fix the problem."
    The problem cannot be fixed by using "Edit" !

    According to AWS support it is possible to accept an endpoint in "Rejected" status - therefore the re-creation of "mongodbatlasprivatelinkendpoint_service" should be working completely and change the endpoint status to "Available".

    Create an AWS endpoint for connection with the (already established) MongoDB Atlas endpoint service -> AWS endpoint is in "Pending acceptance" status.
    Establish the connection with "mongodbatlasprivatelinkendpointservice" -> AWS endpoint goes into "Available" status.
    Destroy the "mongodbatlasprivatelinkendpointservice" connection -> AWS endpoint goes into "Rejected" status.
    Recreate "mongodbatlasprivatelinkendpoint_service" with the same variables -> terraform does recreate he resource, but the resource is not functional.
    In the MongoDB Atlas GUI it shows "Failed. Endpoint failed to reach available state. Click 'Edit' to fix the problem."
    The problem cannot be fixed by using "Edit" !

    … more

    2 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

16. Enable Atlas Device Sync support on Atlas serverless Instances
    1 vote

    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  ·  Serverless Instances  ·  Edit…  ·  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. Allow customization of where $merge creates the temp collection used when rehydrating data from Online Archive --> Atlas

    When you restore data from the Online Archive back into your Atlas cluster (aka "rehydrate") you need to use $merge within an aggregation pipeline. What isn't documented is that $merge will create a temporary collection in the same database you're rehydrating to, which requires that you have readWrite@<dbName> privileges so that the new collection can be created.

    For customers that operate on the "principle of least privilege," where you only grant literally exactly what is needed to accomplish database CRUD operations, the user would the more narrowly scoped "readWrite@<dbName>.<collName>" privilege granted to the user to scope the actions to only the collection itself, thus not opening up readWrite capabilities for other collections in the same DB. For those customers, the $merge will fail with an error like:

    MongoServerError: failed to execute $merge into <DB>.<COLL>: not authorized on <DB> to execute command { aggregate: "tmp.agg_merge.d8af7e12-3f40-4b9c-b0b8-a9aef271a89f", allowDiskUse: false, comment: "via Atlas Data Federation, correlationID = xxxxxxxx", pipeline: [ { $merge: ...

    Since those narrow privileges won't permit the creation of the "tmp.agg_merge.<UUID>" collection within the DB they're rehydrating data to. Adding an option to the $merge aggregation stage that would allow the customer to control which DB the temp collection is created in, or to explicitly specify fully namespace of the temp collection (so that they can pre-grant the privileges needed for the user within Atlas) would allow customers to not have to violate internal security policies in alignment with the "least privilege needed" paradigm.

    When you restore data from the Online Archive back into your Atlas cluster (aka "rehydrate") you need to use $merge within an aggregation pipeline. What isn't documented is that $merge will create a temporary collection in the same database you're rehydrating to, which requires that you have readWrite@<dbName> privileges so that the new collection can be created.

    For customers that operate on the "principle of least privilege," where you only grant literally exactly what is needed to accomplish database CRUD operations, the user would the more narrowly scoped "readWrite@<dbName>.<collName>" privilege granted to the user to scope the actions to only… more

    11 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. Support tagging individual replicas in the cluster

    Thank for the support for the tagging at the cluster level during database deployments( https://feedback.mongodb.com/forums/924145-atlas/suggestions/43032180-support-for-tagging-clusters-in-atlas)

    However it would be useful to have support for tagging individual replicas in the cluster.

    For example., we want to deploy the same app as two deployments tagged as tier-1 and tier-2, with tier-1 deployment service accessing tier-1 tagged readonly replicas and vice-versa.

    4 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  ·  Resource Tagging  ·  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. 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. This does not impact regular operation but also effectively prevents malicious users from causing permanent damage.

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

    7 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  ·  Administration API  ·  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. Support hourly backup every 24 hours, or support Point-In-Time restore without an hourly backup

    To have Point-In-Time restore, an hourly backup policy is required.
    However, the maximal interval for an hourly backup is every 12 hours.
    I would like to take a backup only once every 24 hours, but still have Point-In-Time restore possible.

    So, please support either PIT-restore without an hourly backup policy in place, or support an hourly backup policy with an interval of 24 hours.

    2 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  ·  Backup  ·  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