324 results found

1. VPC between ATLAS/MongoDB/AWS and Heroku/AWS

   Would be a great great feature if we can create a VPC between ATLAS/MongoDB/AWS and Heroku/AWS.
   Thanks.
   Adailton Silva

   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

   1 comment  ·  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. Add option to repair a single collection

   Add support for repairing a single collection instead of what is currently available to repair an entire database via db.repairDatabase()

   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

   1 comment  ·  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. Aggregate $accumulator 'Combine' stage for sharded collections

   After the ‘accumulate’ stage has run against each document on a shard it would be extremely useful to run a script on the shard against the state to reduce the state down to something smaller before passing the final state over the network back to mongos for the ‘merge’. (Over in the Elastic camp they call this the ‘combine_script’).

   Scenario:
   I have a customer orders database sharded by the Customer ID (meaning all data relating to any specific customer is kept on the same shard - so customers don’t need to be ‘merged’ between shards). I can write an accumulator to perform processing across all customer orders on the shard and the wish to perform further processing to reduce the state (containing data spanning various customer orders) down to a minimal state (mostly aggregated customer stats) to then be aggregated by mongos. I wish to avoid copying multiple large state objects (from each shard) across network to the ‘merge’ script on mongos.

   After the ‘accumulate’ stage has run against each document on a shard it would be extremely useful to run a script on the shard against the state to reduce the state down to something smaller before passing the final state over the network back to mongos for the ‘merge’. (Over in the Elastic camp they call this the ‘combine_script’).

   Scenario:
   I have a customer orders database sharded by the Customer ID (meaning all data relating to any specific customer is kept on the same shard - so customers don’t need to be ‘merged’ between shards). I can write an accumulator… 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  ·  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. Assign MongoDB roles to LDAP users

   I would like to create a softlab and therefore give the possibility to a user to create collections in a database which is dedicated to him.

   Currently, to do that I need to :
   1. create a single-member LDAP group for each user
   2. map this group to a MongoDB role authorizing the user's database.

   Create a group with a single member is conceptually useless. I want to avoid step 1.

   My feature request : add the ability to assign MongoDB roles to LDAP users as well as groups.

   Regards,
   Jerome

   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  ·  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. Support for Transaction Savepoints (Nested Transactions)

   The ability to partially rollback transactions to a specified point.

   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

   1 comment  ·  Transactions  ·  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. Allow collection collation to be editable

   Collation of a collection can be set at creation time only. It would be useful to edit these fields to avoid creating an entire new collection and copying the collection over.

   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  ·  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. Add Event Stream Features (Apache Kafka, NATS Streaming)

   I thought it would be great if mongodb can support an event streaming(event bus) feature.
   Existing popular event streaming services(AWS Kinesis, NATS Streaming, Apache Kafka) can persist data which is somewhat like a database.

   Its great for debugging, data logging for later uses such as machine learning. Since I can see the full flow of the data and its changes.

   But there are two downside with most even streaming services.
   1. Its very difficult to query the data.
   2. "Eventual Consistency" issue when dealing programmatic errors(bugs). Most event streams have this nice feature, which keeps sending the same event to a subscriber until the subscriber acknowledges that the event has been published. Now this is really great in terms of temporary issues(network problem, service restart due to deployment, etc.). But if the cause of failure is a bug, which needs fixing by a developer, the event bus should not continuously send same event again and again.

   To solve this issue, I made a micro service that subscribes to all events and store the events in mongodb, basically I store the event data both in mongo and stream service.
   Now its super easy to query(since "event chain" is a tree structure for every child event I store the parent event Id)
   Also I dont only store events but event errors with its parent event Id and error stack trace. With this I made a small feature that counts the number of duplicate errors. When the number of duplicate error exceeds a certain number, we can assume that its not a temporary error and so the event bus is programmatically acknowledged.
   After the developer fixes the issue the developer can relaunch the same event based on what is stored in mongodb.
   Now one major issue people might come up with this solution is that a lot of data is generated in mongo, which are not queried regularly.
   Well in this case I think I can make use of mongodb data lake/ For example I could only store recent 7 days of events in mongodb and after 7days I could make a data pipeline that exports data to S3 and if I need to query I would use mongodb data lake.

   After building this service and duplicating the events from the event stream to mongodb, I thought it would be great if mongodb supports a built in feature. This feature would be especially great for mongodb compared to other databases(relational) because events in general are objects(documents)

   I thought it would be great if mongodb can support an event streaming(event bus) feature.
   Existing popular event streaming services(AWS Kinesis, NATS Streaming, Apache Kafka) can persist data which is somewhat like a database.

   Its great for debugging, data logging for later uses such as machine learning. Since I can see the full flow of the data and its changes.

   But there are two downside with most even streaming services.
   1. Its very difficult to query the data.
   2. "Eventual Consistency" issue when dealing programmatic errors(bugs). Most event streams have this nice feature, which keeps sending the same event to… 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

   1 comment  ·  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. Performance problem with compound index using doubles, with range filtering

   It looks like there may be a problem when using doubles in a compound index and using range-test filters against all of them in a query.
   The problem we see from the explain plans is that far more keys are being examined that there should be and this leads to poor performance.
   If we switch to using a similar setup but with integers instead, we don’t see the problem.

   See the second part of this ticket for full details

   https://support.mongodb.com/case/00659614

   We have a document that looks like this –

   {
   "id" : ObjectId("5e2ab24eca314f10b486d827"),
   "attributes" : [
   {
   "attributeCode" : "attributesitemsGeometry",
   "boundingBox" : {
   "lonMin" : -1.93181854783035,
   "latMin" : 52.1718902305398,
   "lonMax" : -1.9244498979136,
   "latMax" : 52.1749938832085
   }
   }
   ]
   }

   With a compound index like this –

   {
       "v" : 2,
       "key" : {
           "attributes.boundingBox.lonMin" : 1,
           "attributes.boundingBox.lonMax" : 1,
           "attributes.boundingBox.latMin" : 1,
           "attributes.boundingBox.latMax" : 1        },
       "name" : "itemVersions_designCode_collection_attributeCode_boundingBox_date",
       "ns" : "customerBlah.itemVersions"
   }
   

   And we make queries with range filters like this

   "attributes" : {
   "$elemMatch" : {
   "$and" : [

   {
   "boundingBox.latMin" : {
   "$lte" : 52.0751028974155
   }
   },
   {
   "boundingBox.lonMin" : {
   "$lte" : -1.92557202436271
   }
   },
   {
   "boundingBox.latMax" : {
   "$gte" : 52.0729000493818
   }
   },
   {
   "boundingBox.lonMax" : {
   "$gte" : -1.92931078813729
   }
   }

   It looks like there may be a problem when using doubles in a compound index and using range-test filters against all of them in a query.
   The problem we see from the explain plans is that far more keys are being examined that there should be and this leads to poor performance.
   If we switch to using a similar setup but with integers instead, we don’t see the problem.

   See the second part of this ticket for full details

   https://support.mongodb.com/case/00659614

   We have a document that looks like this –

   {
   "id" : ObjectId("5e2ab24eca314f10b486d827"),
   "attributes" : [
   {
   "attributeCode" :… 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  ·  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. Too many keys in 2dsphere index when used on geoJson within arrays

   Mongo support have asked me to raise this bug as an improvement idea because they see it as an edge case.
   The issue is here and includes more details:

   https://support.mongodb.com/case/00659614

   In summary, if you have a geoJson sub document that sits within an array, and you index it using the 2dspehere index, you get keys duplicated for every element in the array.

   For example, if you have geoJson that represents a big 4,500 vertex polygon, and you put it within an array element, if the array has only one element I see 20 keys generated, which is good. But if you have another element in the array that doesn’t have any geoJson, another 20 keys are generated, now totaling 40 keys for that document.

   In our application this bug can cause the index memory requirements for 2dsphere to become a serious concern.

   We have stopped using the index and developed an alternative.

   Mongo support have asked me to raise this bug as an improvement idea because they see it as an edge case.
   The issue is here and includes more details:

   https://support.mongodb.com/case/00659614

   In summary, if you have a geoJson sub document that sits within an array, and you index it using the 2dspehere index, you get keys duplicated for every element in the array.

   For example, if you have geoJson that represents a big 4,500 vertex polygon, and you put it within an array element, if the array has only one element I see 20 keys generated, which is good. But if… 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  ·  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. Making Elections Faster.

    Election is an expensive operation. We can avoid the elections if we can enforce some priority-based ordering on who shall become primary if the current primary fails.
    Specifically, we can keep a node with second highest priority in the data center of the most preferred primary. Usually, the network failures within the data centers are less probable than across the data centers. So, it is reasonable to believe that if the second preferred member loses the contact with current primary, it is the primary node which has failed and not the network. As a supplement, we can also have redundant network connection between the two. So, we do not need to wait for 10 seconds to detect that it is a node failure. Write operations can immediately shift to the second preferred member and this would make system “more” available for writes.

    Election is an expensive operation. We can avoid the elections if we can enforce some priority-based ordering on who shall become primary if the current primary fails.
    Specifically, we can keep a node with second highest priority in the data center of the most preferred primary. Usually, the network failures within the data centers are less probable than across the data centers. So, it is reasonable to believe that if the second preferred member loses the contact with current primary, it is the primary node which has failed and not the network. As a supplement, we can also have redundant… 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  ·  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. Please include accurate product edition information (Enterprise vs. Community) within the Windows version of mongod.exe.

    Dear MongoDB Support Team,

    I would like to request an enhancement to the Windows version of your MongoDB software. Specifically, please consider including accurate product edition information (Enterprise vs. Community) within the mongod.exe executable.

    Currently, the only reliable method to distinguish between editions is through shell-based verification commands. This limitation adds complexity to enterprise software management and version auditing processes. Embedding edition metadata directly within the executable would significantly streamline identification and improve administrative efficiency.

    Thank you for considering this request. Please let me know if any additional details are needed.

    Best regards,
    Patricia Wu

    •  

    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  ·  Administration  ·  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

12. Support to Export snapshots from clusters in an Atlas project with private endpoints enabled
    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  ·  Administration  ·  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

13. Support default values in validation

    Many MongoDB users feel that default values should be supported in validation. See, for example:
    https://www.mongodb.com/community/forums/t/setting-default-values-in-data-schema/8411
    https://www.mongodb.com/community/forums/t/support-default-value-in-schema-validation/319684

    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 Models  ·  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. Provide a dictionary for matched/modified/deleted counts for bulk writes

    Current bulk write operations provide only aggregated counts that look like this:
    
{
acknowledged: true,
insertedCount: 0,
insertedIds: {},
matchedCount: 2,
modifiedCount: 2,
deletedCount: 0,
upsertedCount: 0,
upsertedIds: {}
}

    All these operations are processed individually by the server, even if out of order, meaning that the current Mongo DB code aggregates these individual counts in order to present them in the structure above.

    This aggregation, however, makes it impossible to use bulk writes in the same way single updates and deletes can be performed, which significantly slows down mass updates.

    Consider updates of versioned documents - one can issue 100 updates, where a version is a part of a criteria. If updates would be tracked in the same way inserts/upserts are (with relation to their operation index, not document IDs, which would be an overkill), there would be a dictionary in the bulk result object, with the bulk operation index as a key and the number of matched and modified or deleted document as the value.

    This way callers could identify that, say 90 of those 100 versioned updates were successful and 10 were not and then use client-side mapping between those bulk operations in the original structures to infer which ones failed, so the failed document could be reported as needed, such as reporting stale versions, etc.

    Current bulk write operations provide only aggregated counts that look like this:
    
{
acknowledged: true,
insertedCount: 0,
insertedIds: {},
matchedCount: 2,
modifiedCount: 2,
deletedCount: 0,
upsertedCount: 0,
upsertedIds: {}
}

    All these operations are processed individually by the server, even if out of order, meaning that the current Mongo DB code aggregates these individual counts in order to present them in the structure above.

    This aggregation, however, makes it impossible to use bulk writes in the same way single updates and deletes can be performed, which significantly slows down mass updates.

    Consider updates of versioned documents - one can issue… 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  ·  Performance  ·  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. x509 Authentication Supports Multiple CA's

    I work for a large entity with a complicated security certificate structure where we are unable to create certs with specific CA's but rather they are issued to us by request and thus we don't always have control over the root or intermediate CA in the chain.
    We have a situation where server certificates are signed with one CA but client certificates are signed with a different CA. All the CA's are installed and trusted in our Windows certificate store, but the current limitation of Mongo is it only supports a single CA.
    Would it be possible for Mongo to support more than one CA?

    I work for a large entity with a complicated security certificate structure where we are unable to create certs with specific CA's but rather they are issued to us by request and thus we don't always have control over the root or intermediate CA in the chain.
    We have a situation where server certificates are signed with one CA but client certificates are signed with a different CA. All the CA's are installed and trusted in our Windows certificate store, but the current limitation of Mongo is it only supports a single CA.
    Would it be possible for Mongo to… 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  ·  Security  ·  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

16. Certificate "friendlyName" (windows system certificate store)

    mongod.exe:
    currently there is only support for "subject" and "thumbprint" to select the certificate from the windows certificate store.
    Is there a plan to implement the "friendly name" of the certificate as well?

    example mongod.cfg:
    ..
    tls:
    mode: requireTLS
    certificateSelector: friendlyname=FRIENDLY-NAME

    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

17. deleteMany() execution automatically disable the balancer on sharded clusters

    deleteMany() execution automatically disable the balancer on sharded 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  ·  Sharding  ·  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

18. Execute $group on shardPart instead of mergerPart

    Basically what is described here: https://www.mongodb.com/community/forums/t/how-to-enforce-mongodb-to-execute-group-on-shardpart-of-the-execution-plan/267560

    When running covered count queries that could be aggregated independently on the shards, there is still a lot of overhead due to the fact that shards have to report documents with _id to mongos

    It looks like this is happening for count queries that use $limit stage, but not for count queries without it

    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  ·  Performance  ·  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

19. Support for proxy protocol on mongod

    Hi,

    I have mongodb database server running as a container on kubernetes and i have istio as ingress, but i need proxy protocol in order to preserve source ip, because without proxy protocol the client ip that arrives in mongodb server is the ip from the istio ingress gateway.

    I know mongos already supports it for sharded clusters, but would be very helpfully if mongod could support proxy protocol as well.

    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

20. Option Renaming Time Series Collections

    Ability to rename TS collection . We need it for migration history data to TS without downtime during conversion.

    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  ·  Time Series  ·  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