302 results found

1. Amazon Linux 2023 Support for MongoDB 6.0 and OpsManager 6.0

   Amazon Linux 2023 is supported in rapid releases from 6.2.0 and will be supported in the upcoming 7.0 release of MongoDB, however it appears there is currently no plan to support AL2023 for the 6.0 release of MongoDB. Can support for AL2023 be added to the 6.0 branch for both MongoDB and OpsManager?

   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

2. Support indexes on single array elements (e.g. "MyArray.0")

   Currently, if I create an index on an array field and specify an element number ("MyArray.0"), the system still indexes the whole array as normal.

   Normally, this might increase the index size but at least it's still useful when querying MyArray.0 later.

   However, it would be better to be able to index individual numbered elements in cases like compound indexes where I might need to check whether two arrays are non-empty, and I can't use a compound index for a query on MyArray.0 and MyOtherArray.0 at the same time due to the multi-array limitation.

   For MongoDB folks with access to it, see support case 01158569 for a scenario where I needed this capability, and a discussion about it.

   Currently, if I create an index on an array field and specify an element number ("MyArray.0"), the system still indexes the whole array as normal.

   Normally, this might increase the index size but at least it's still useful when querying MyArray.0 later.

   However, it would be better to be able to index individual numbered elements in cases like compound indexes where I might need to check whether two arrays are non-empty, and I can't use a compound index for a query on MyArray.0 and MyOtherArray.0 at the same time due to the multi-array limitation.

   For MongoDB folks with access 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  ·  Indexes  ·  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

3. Implement $bucket and $group on indexed values with sub-linear runtime

   We noticed that sum $bucket and $group aggregations such as $min, $max, $count are unexpectedly slow even when fully covered by an index, (partially) because the DB scans through the entire index rather than employing optimization approaches such as binary search.

   An example pipeline that should return instantaneous but scans through the entire index (confirmed on v4.4 and v5):
   [
   {
   $match: {
   status: "DELIVERED",
   },
   },
   {
   $group: {
   id: {
   status: "$status",
   },
   min: {
   $min: "$modifytime",
   },
   },
   },
   ]
   with an index { status: 1, modify_time: 1}

   Another example is $bucket (same index):
   [
   {
   $match: {
   status: "DELIVERED",
   },
   },
   {
   $bucket: {
   groupBy: "$creation_ts",
   boundaries: [
   Date(0),
   ISODate("2020-01-01T00:00:30Z"),
   ISODate("2022-01-01T00:00:30Z"),
   ],
   default: "default",
   output: {
   count: {
   $sum: 1,
   },
   status: {
   $first: "$status",
   },
   },
   },
   },
   ]

   We noticed that sum $bucket and $group aggregations such as $min, $max, $count are unexpectedly slow even when fully covered by an index, (partially) because the DB scans through the entire index rather than employing optimization approaches such as binary search.

   An example pipeline that should return instantaneous but scans through the entire index (confirmed on v4.4 and v5):
   [
   {
   $match: {
   status: "DELIVERED",
   },
   },
   {
   $group: {
   id: {
   status: "$status",
   },
   min: {
   $min: "$modifytime",
   },
   },
   },
   ]
   with an index { status: 1, modify_time: 1}

   Another example is $bucket (same index):
   [
   {… more

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

4. Support compound/multiple grouping keys in $bucket

   We often need to compute statistical/summarizing aggregations grouped by more than one field where all fields are of a $bucket-able type.

   An example, would be to count all orders grouped by their status and some custom time ranges of their creation date.
   This can be achieved by using $group in combination with a $switch expression (sometimes simplified with $trunc), however, that is cumbersome and prevents efficient grouping since e.g. no binary search can be employed to identify the bucket boundaries efficiently.

   The query syntax of $bucket would not need to change much. It would simply need to allow for nested arrays within the boundaries parameter whereby each nested array specifies the requested grouping range.

   We often need to compute statistical/summarizing aggregations grouped by more than one field where all fields are of a $bucket-able type.

   An example, would be to count all orders grouped by their status and some custom time ranges of their creation date.
   This can be achieved by using $group in combination with a $switch expression (sometimes simplified with $trunc), however, that is cumbersome and prevents efficient grouping since e.g. no binary search can be employed to identify the bucket boundaries efficiently.

   The query syntax of $bucket would not need to change much. It would simply need to allow for nested… more

   6 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  ·  Query and Aggregation Pipeline  ·  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

5. Budget limit for serverless pay as you go mode

   I was looking at the serverless pay-as-you-go option for my DB so I could have continuous backup and snapshots but I found it too risky. Currently, the only protection user has is alerts when RPUs go over a certain budget threshold. I would like to be able to set a budget limit that would prevent me from going over pre-set daily budget. If you would get hit with DOS or some other brute force attack you could rack up lots of traffic and get an unexpected bill without a potential limit.

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

6. Add operator that would calculate distance between 2 geolocation points

   It would be great to have operator that would calculate distance between 2 geolocation points, and not to do it manually with big aggregate queries.

   I suggest to add 2 new operators that would calculate distance in two different ways, as discussed in this Community Post: https://www.mongodb.com/community/forums/t/how-to-calculate-distance-between-two-geolocation-points/173045

   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

   3 comments  ·  Query and Aggregation Pipeline  ·  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

7. Handle Daylight Saving Time when $densify is used on a date field

   When using "day" as "unit" for a $densify pipeline stage on a date field, the date is always advanced of 24 hours. This is however not always the expected result in timezones in which the year has one 23-hour and one 25-hour long day, because of Daylight Saving Time.

   It would be useful to have the possibility to pass an optional timezone parameter in the $densify stage and, when present, have the stage account for these exceptions when appropriate.

   Here follows an example.

   Assume we have a collection containing the following documents:

   db.densifyDateExample.insertMany([
       {_id: "a", d: ISODate("2022-10-28T22:00:00Z")},
       {_id: "b", d: ISODate("2022-10-29T22:00:00Z")},
       {_id: "c", d: ISODate("2022-10-30T23:00:00Z")},
       {_id: "d", d: ISODate("2022-10-31T23:00:00Z")},
       {_id: "e", d: ISODate("2022-11-01T23:00:00Z")},
       {_id: "f", d: ISODate("2022-11-02T23:00:00Z")}
   ])
   

   Keep in mind that on 2022-10-30, in EU countires, the time switched from CEST to CET. So those are the UTC representations of the beginning of the days from Oct 29th to Nov 3rd.

   Now, if we run the following pipeline:

   db.densifyDateExample.aggregate([{
       $densify: {
           "field": "d",
           "range": {
               "bounds": [ISODate("2022-10-25T22:00:00.000Z"), ISODate("2022-11-06T23:00:00.000Z")],
               "step": 1,
               "unit": "day"
           }
       }
   }])
   

   We get the following result:

   { "d" : ISODate("2022-10-25T22:00:00Z") }
   { "d" : ISODate("2022-10-26T22:00:00Z") }
   { "d" : ISODate("2022-10-27T22:00:00Z") }
   { "_id" : "a", "d" : ISODate("2022-10-28T22:00:00Z") }
   { "_id" : "b", "d" : ISODate("2022-10-29T22:00:00Z") }
   { "d" : ISODate("2022-10-30T22:00:00Z") }
   { "_id" : "c", "d" : ISODate("2022-10-30T23:00:00Z") }
   { "d" : ISODate("2022-10-31T22:00:00Z") }
   { "_id" : "d", "d" : ISODate("2022-10-31T23:00:00Z") }
   { "d" : ISODate("2022-11-01T22:00:00Z") }
   { "_id" : "e", "d" : ISODate("2022-11-01T23:00:00Z") }
   { "d" : ISODate("2022-11-02T22:00:00Z") }
   { "_id" : "f", "d" : ISODate("2022-11-02T23:00:00Z") }
   { "d" : ISODate("2022-11-03T22:00:00Z") }
   { "d" : ISODate("2022-11-04T22:00:00Z") }
   { "d" : ISODate("2022-11-05T22:00:00Z") }
   { "d" : ISODate("2022-11-06T22:00:00Z") }
   

   While - after somehow telling $densify in which timezone we are working - the following would be way more useful:

   { "d" : ISODate("2022-10-25T22:00:00Z") }
   { "d" : ISODate("2022-10-26T22:00:00Z") }
   { "d" : ISODate("2022-10-27T22:00:00Z") }
   { "_id" : "a", "d" : ISODate("2022-10-28T22:00:00Z") }
   { "_id" : "b", "d" : ISODate("2022-10-29T22:00:00Z") }
   { "_id" : "c", "d" : ISODate("2022-10-30T23:00:00Z") }
   { "_id" : "d", "d" : ISODate("2022-10-31T23:00:00Z") }
   { "_id" : "e", "d" : ISODate("2022-11-01T23:00:00Z") }
   { "_id" : "f", "d" : ISODate("2022-11-02T23:00:00Z") }
   { "d" : ISODate("2022-11-03T23:00:00Z") }
   { "d" : ISODate("2022-11-04T23:00:00Z") }
   { "d" : ISODate("2022-11-05T23:00:00Z") }
   { "d" : ISODate("2022-11-06T23:00:00Z") }
   

   When using "day" as "unit" for a $densify pipeline stage on a date field, the date is always advanced of 24 hours. This is however not always the expected result in timezones in which the year has one 23-hour and one 25-hour long day, because of Daylight Saving Time.

   It would be useful to have the possibility to pass an optional timezone parameter in the $densify stage and, when present, have the stage account for these exceptions when appropriate.

   Here follows an example.

   Assume we have a collection containing the following documents:

   db.densifyDateExample.insertMany([
       {_id: "a", d: ISODate("2022-10-28T22:00:00Z")},
       {_id: "b", d:

   … 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

   1 comment  ·  Query and Aggregation Pipeline  ·  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

8. Metadata for collections

   I would like to be able to store metadata about a collection such as a description or link to sources, along with the name of the collection.

   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

9. sharding error shardsvr

   Make it clear which node is causing the "shardsvr" error.

   Spawned from support case 01042995

   Our error occurred when the user tried to connect using Compass. The failure was to list the collection names on one database.

   The error presented back to the user was merely Cannot accept sharding commands if not started with --shardsvr

   We found eventually that the primary changed on one of the shards, and that primary did not have the appropriate clusterRole in the mongod.conf file. My concerns are that this took too long to track down and would be impossible in a 100-shard environment.

   • Nothing in sh.status() indicated that there was any problem connecting to those nodes
   • Nothing in the mongos.log file indicated which node was providing that error

   Make it clear which node is causing the "shardsvr" error.

   Spawned from support case 01042995

   Our error occurred when the user tried to connect using Compass. The failure was to list the collection names on one database.

   The error presented back to the user was merely Cannot accept sharding commands if not started with --shardsvr

   We found eventually that the primary changed on one of the shards, and that primary did not have the appropriate clusterRole in the mongod.conf file. My concerns are that this took too long to track down and would be impossible in a 100-shard environment.

   • Nothing… more
   6 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  ·  System Observability  ·  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

10. tail queries functionality

    We'd like to log the underlying MongoDB queries issued against the database. Similar to https://github.com/mrsarm/mongotail but something official

    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  ·  System Observability  ·  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

11. Change stream Monitoring/Aletring in management

    how to monitor change stream activity per namespace
    1. Number of Change streams per namespace
    2. Set + Manage the allowed number of change streams
    3. A metrics UI tab for OpsManager.
    4. Alert if the number of change streams exceeds the set limit.

    This will assist in managing the cluster and also avoiding any issue that may arise from highly demanding change streams that take up RAM and compute.

    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  ·  Change Streams  ·  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

12. One of the waste application, often times it is ip address was automatically disconected and throw some lot of errors waste application
    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

13. Support change streams without service discovery

    Currently, change streams are not supported in standalone instances, so testing change stream functionality requires a one-node replica set. However, promoting a standalone node to a one-node replica set requires a call to rs.initiate(config), which requires host and port information so that clients can connect; something that is not required for standalone nodes. This means change stream support is conflated with service discovery. It becomes impossible, for example, to create a docker image that boots as a single-node replica set, while it's trivial to make a docker image that boots as a standalone server.

    Various ideas that would make this easier:

    1. Make rs.initiate() (with no configuration) default to a single-node cluster that clients connect to using the host and port from their connection string. (Current behaviour defaults to "localhost:27017" which is risky, since it can cause two separate single-node replica sets to be quietly interconnected if one of them happens to be on localhost:27017.)

    2. Support change streams in standalone nodes. While it's understandable that standalone nodes don't support change streams because they have no oplog, this is still a rather major omission in the functionality of standalone nodes.

    Currently, change streams are not supported in standalone instances, so testing change stream functionality requires a one-node replica set. However, promoting a standalone node to a one-node replica set requires a call to rs.initiate(config), which requires host and port information so that clients can connect; something that is not required for standalone nodes. This means change stream support is conflated with service discovery. It becomes impossible, for example, to create a docker image that boots as a single-node replica set, while it's trivial to make a docker image that boots as a standalone server.

    Various ideas that would make… 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  ·  Change Streams  ·  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

14. Avoid truncating the query on the Atlas profiler or system.profile collection

    Slow running queries that are captured in system.profile collection or on profiler page of Atlas are truncated if the query is too long. As an Application DBA, it would be difficult to analyse the query without figuring out the actual query. The current limitation of command document is 50Kb. Request you to consider this limitation to avoid truncation of queries.

    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

15. geo

    It would be nice to get the length of an LineString of a geo-json object or the possibility to write an aggregation to calculate it.

    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  ·  Query and Aggregation Pipeline  ·  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

16. Expose individual command execution time

    Many MongoDB drivers currently expose events (CommandSucceededEvent say) which provide an elapsed time. However, that elapsed time is the round-trip time, which is not super useful as that can be measured by a programmer manually. It would be neat if there was a way to get the actual time spent by the server on a per-command basis. This data is computed somewhere as it is exposed in Atlas metrics as Execution Time.

    There's the explain facility but this is just to get an estimate of a query's cost. I would be interested in knowing how much time the server spent running an actual command. Latency could then be computed by subtracting this value from the round-trip time.

    Many MongoDB drivers currently expose events (CommandSucceededEvent say) which provide an elapsed time. However, that elapsed time is the round-trip time, which is not super useful as that can be measured by a programmer manually. It would be neat if there was a way to get the actual time spent by the server on a per-command basis. This data is computed somewhere as it is exposed in Atlas metrics as Execution Time.

    There's the explain facility but this is just to get an estimate of a query's cost. I would be interested in knowing how much time the server spent… 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  ·  System Observability  ·  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

17. Use a private peering that resolves to the private IP address of your LDAP server.

    We need to consume an LDAP server traffic through Private Endpoints. In the documentation we find that only creating a public endpoint it's possible but we have a security restriction. Our TAM suggested create a feedback request to the product owner.
    tks!

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

18. Improve fortification coverage with _FORTIFY_SOURCE=3

    MongoDB Server codebase uses _FORTIFY_SOURCE=2 fortification level (e.g. see v7.0, latest at the moment: https://github.com/mongodb/mongo/blob/v7.0/SConstruct#L4698).
    Consider changing it to a new fortification level (_FORTIFY_SOURCE=3) provided by GCC 12 to improve DB's security.

    See also:
    https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
    https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level

    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

19. I believe the future is for AI to assist the user in simple but sometimes frustrating tasks like connecting or finding the correct build

    An Artificial Intelligence assistance would be very useful to the user for finding the correct configuration and helping set up connections. There are many deprecated components, especially if you are trying to integrate a IoT platform like Raspberry Pi. It would be great for the system to recognize what you are trying to do and guide you along the right path.

    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

20. amazon linux 2023 (AL2023) support for ARM

    Amazon Linux 2023 (AL2023) support for ARM (MongoDB and CloudManager)

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