272 results found

1. Allow live migration using private interface

   There should be an option to live migrate data via a private interface instead of public one. With VPC being peered, it would be a great option to avoid exposing database to the public interface (even if it's specific set of IPs). This can resolve concerns of many customers who are following or need to follow some short of compliance on their end.

   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

2. an aggregation stage to load data to DRAM for the fields that are only requested

   When we use $project stage, it loads whole document from disk to memory (if not in working set). Because of this, When we create a data model, We have to create separate collection if the field is not required in frequent access of data. Creating a view is an option, but what if $project itself or $project with some argument in it, or a new pipeline stage or operator gets introduced which fetches the data from disk only for the fields specified instead of loading whole document.

   With memory mapped file, retrieving fields specified alone would not be simply possible but just thinking of a possibility which can be really useful in a case.

   When we use $project stage, it loads whole document from disk to memory (if not in working set). Because of this, When we create a data model, We have to create separate collection if the field is not required in frequent access of data. Creating a view is an option, but what if $project itself or $project with some argument in it, or a new pipeline stage or operator gets introduced which fetches the data from disk only for the fields specified instead of loading whole document.

   With memory mapped file, retrieving fields specified alone would not be simply possible… 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

3. Unique Indexes and Bulk Upserts for Time Series Collections

   We would like to insert data in bulk into time series collections and identify the new data that has been inserted without the possibility of duplicates being inserted.

   For regular collections this is achievable by adding a unique index and performing a bulk upsert (as any duplicates will be rejected due to the unique index).

   For time series collections however unique indexes are not currently supported.

   In addition performing an upsert with $setOnInsert option which should only action insert operations is also not currently supported for time series collections.

   At the moment the only options appear to be:

   (1) to process records one at a time, checking for a matching record by performing a find operation and inserting the record if no match is found.

   (2) to allow duplicates to be inserted and to create an aggregation pipeline using a $group stage to filter out the duplicates from users accessing the data.

   (3) to use regular collections so that unique indexes and upserts are supported.

   None of the options available at the moment are ideal.
   
   - Option (1) isn't particularly efficient.
   - Option (2) doesn't allow duplicates to be identified as part of the ingestion.
   - Option (3) doesn't allow us to take advantage of the benefits and optimizations that come with timeseries collections such as optimized internal storage and improved query efficiency.

   The preference would be for MongoDB to support Unique Indexes and Bulk Upserts for Time Series Collections.

   We would like to insert data in bulk into time series collections and identify the new data that has been inserted without the possibility of duplicates being inserted.

   For regular collections this is achievable by adding a unique index and performing a bulk upsert (as any duplicates will be rejected due to the unique index).

   For time series collections however unique indexes are not currently supported.

   In addition performing an upsert with $setOnInsert option which should only action insert operations is also not currently supported for time series collections.

   At the moment the only options appear to be:

   (1) to… 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  ·  Time Series  ·  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. Nanosecond timestamp support

   I've put this under the time series category since that's where it's most applicable, but it's really a data model / BSON issue.

   The topic of higher resolution timestamps have been surfaced from time to time for at least a decade (https://jira.mongodb.org/browse/SERVER-1460), and usually prompts a response like "just use integers". With the addition of time series collections however, where the concept of time is integral to database functionality, I think it's time to reconsider adding a type with at least nanosecond precision timestamp support. Date's millisecond resolution is woefully inadequate for a number of relevant use cases, be it sensor data, financial data, log data, etc.

   I've put this under the time series category since that's where it's most applicable, but it's really a data model / BSON issue.

   The topic of higher resolution timestamps have been surfaced from time to time for at least a decade (https://jira.mongodb.org/browse/SERVER-1460), and usually prompts a response like "just use integers". With the addition of time series collections however, where the concept of time is integral to database functionality, I think it's time to reconsider adding a type with at least nanosecond precision timestamp support. Date's millisecond resolution is woefully inadequate for a number of relevant use cases,… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Time Series  ·  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. add IO throughput related fields to 'serverStatus' output

   There is no IO throughput related fields in the result of serverStatus, instead in FTDC this is available in the disk metrics.
   Need it in serverStatus output so that we can monitor it.

   3 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

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

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

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

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

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

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

12. Collection which stores last login date_time for the users

    Are you please able to store the last login date_time for the users which exist either in admin database or $external database in a collection of admin database of that cluster or opsmanager database which manages the clusters?

    I have a requirement at my end - is to find the users who havent logged in for 60 days, , their roles to be revoked. And, ultimately delete the users who dont have any roles attached after a fixed period of time.

    I do undertsnad you store the login details in audit logs. But that would be a tedious process at our end, to write a code which parses the audit log files and then maintains our own (duplicate) collection of users and updates it with the last login time information as obtained from the audit logs. Thereafter, compare this collection with the collection in system.users of admin database or $external database to see the users who havent logged in for a while.

    Thank you

    Are you please able to store the last login date_time for the users which exist either in admin database or $external database in a collection of admin database of that cluster or opsmanager database which manages the clusters?

    I have a requirement at my end - is to find the users who havent logged in for 60 days, , their roles to be revoked. And, ultimately delete the users who dont have any roles attached after a fixed period of time.

    I do undertsnad you store the login details in audit logs. But that would be a tedious process at… 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  ·  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. 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

14. Add timestamps to user documents

    Most database technologies store this metadata by default.
    Because the expected data volume and change rate of this attribute will most probably be low, there should be no reason of not storing this information.
    Of course this information might already be available in audit files, but first: auditing isn't enabled by default.
    Second: most database users won't have access to this file/info and third: most users won't expect this info in a separate file (reminder, MongoDB recommends to store the data where it belongs when it comes to "data/schema modelling", so the metadata of a user document should also be located within this document!).

    Most database technologies store this metadata by default.
    Because the expected data volume and change rate of this attribute will most probably be low, there should be no reason of not storing this information.
    Of course this information might already be available in audit files, but first: auditing isn't enabled by default.
    Second: most database users won't have access to this file/info and third: most users won't expect this info in a separate file (reminder, MongoDB recommends to store the data where it belongs when it comes to "data/schema modelling", so the metadata of a user document should also be… 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

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

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

17. Extend schema validation to be able to enforce referential integrity between collections

    Where a relational database uses 2 tables to store a 1:many "parent - child" relationship between entities, MongoDB mostly stores the child documents in an array file as part of the parent document. This automatically ensures referential integrity in that
    - a child document cannot be inserted or updated to refer to a non-existent parent, and
    - a parent document cannot be deleted such that it leaves "orphaned" child documents

    However, there are situations where the number and/or size of the child documents makes embedding them all in their parent unworkable, due to the 16 megabyte document size limit if nothing else.

    In those cases, the documents are stored in separate collections, and schema validation cannot enforce the integrity of the references between them.

    Schema validation already permits rules to be specified as $expr expressions for rules based on multiple fields in the document being inserted/updated, like "totalCost = basePrice + taxAmount".

    One way this enhancement could be implemented is by extending the use of $expr to permit use of an aggregation pipeline that does a $lookup to the other collection.

    Where a relational database uses 2 tables to store a 1:many "parent - child" relationship between entities, MongoDB mostly stores the child documents in an array file as part of the parent document. This automatically ensures referential integrity in that
    - a child document cannot be inserted or updated to refer to a non-existent parent, and
    - a parent document cannot be deleted such that it leaves "orphaned" child documents

    However, there are situations where the number and/or size of the child documents makes embedding them all in their parent unworkable, due to the 16 megabyte document size limit if… more

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Data Models  ·  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. $merge

    Report number of docs matched, merged, skipped, etc. from a $merge stage. Alternatively, return the merged doc results as a pipeline result to pass to additional stages.

    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

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

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