243 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. Should be possible to configure profiling output destination

   When enabling database profiling the output is sent to both the system.profile collection and system logs. Logging to a capped collection is fine but spamming the logs on disk is not good.

   We have a need to be able to react to changing query patterns quickly, so we have profiling enabled in production on a busy system and we do real-time analysis on the the system.profile collection. This works fine and the performance hit is acceptable but our system logs on disk grows a lot.

   Please make it possible to configure if profile logging should go to disk, collection or both. Ideally with individual levels.

   When enabling database profiling the output is sent to both the system.profile collection and system logs. Logging to a capped collection is fine but spamming the logs on disk is not good.

   We have a need to be able to react to changing query patterns quickly, so we have profiling enabled in production on a busy system and we do real-time analysis on the the system.profile collection. This works fine and the performance hit is acceptable but our system logs on disk grows a lot.

   Please make it possible to configure if profile logging should go to disk, collection or… more

   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

   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. API for Index

   An API to GET existing indexes in a cluster. The post to create already exists, but I wanted to validate that the index did not yet exist.

   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

5. Allow to define access to DBs/collections by prefix or pattern.

   Please extend ACL to support prefixes (or regex) in the database name/collection.
   Currently only allowed ALL (when empty string provided) or exact db/collection matching when provided.

   Use case: Several services are using the same cluster but need to be isolated. Every service can get readWriteAnyDatabase but only to databases prefixed by some prefix.
   Services need to create new databases on the fly, so it is not possible to define a list of databases upfront.

   For example - rwRoleForService1 allows "update", "insert", and "remove" operations only on databases prefixed by "service1-" (sevice1-db1, sevice1-db2, ....)
   {
   role: "rwRoleForService1",
   privileges: [
   {
   { resource: { db: "service1-", collection: "", dbPatternType: PREFIX },
   actions: [ "update", "insert", "remove" ] },
   },
   ...
   ],
   ...
   }

   dbPatternType/collectionPatternType can be:
   LITERAL (by default) - A literal resource name.
   PREFIX - A prefixed resource name.
   REGEX - Will perform pattern matching.

   Please extend ACL to support prefixes (or regex) in the database name/collection.
   Currently only allowed ALL (when empty string provided) or exact db/collection matching when provided.

   Use case: Several services are using the same cluster but need to be isolated. Every service can get readWriteAnyDatabase but only to databases prefixed by some prefix.
   Services need to create new databases on the fly, so it is not possible to define a list of databases upfront.

   For example - rwRoleForService1 allows "update", "insert", and "remove" operations only on databases prefixed by "service1-" (sevice1-db1, sevice1-db2, ....)
   {
   role: "rwRoleForService1",
   privileges: [
   {
   {… 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  ·  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

6. When was last backup/mongodump ran on databases or database backup history

   How can get detail of last backup was taken using query. Its very hard to get into log file and see the history of mongodump. Just like other database tool mongodump history can be retrieved via query instead mongo log file.

   I know get the detail from ops manager if using enterprise only but what if we are using community edition.

   If you include this feature it will very helpful for DBA to get the details juts like other database tools available in market.

   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

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

7. Tool for score data model

   It would be great to have a tool which can scores a data model from a specific database. I mean, I could allows this tool to scan a database model and score this data model based on best practices, patterns and anti patterns. It could also generates a list of problems and suggestions for improvement.

   This tool could be used on CI pipelines near to the unit tests and the main goal is to avoid release new features using a bad data model.

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

8. Improve Atlas suggested indexes

   Suggested indexes
   - Currently it will suggest indexes that can't be created, such as with multiple array fields.
   -- This should be detectable before suggesting an index.
   -- Highlight array fields in the suggested index
   - Include partial index expressions
   - Make more than one suggestion for queries

   Trying to create an index that contains multiple array fields (for some documents being indexed) won't fail until it hits one such document.
   - Pre-parse to first confirm the fields being indexed don't include more than 1 array for the index?
   - Pre-parse and inform the user if any of the fields are arrays for the index scope
   - Pre-parse and make suggestions, like partial index expressions

   Query execution planner
   - It appears that the query execution planner doesn't take into account partial index expressions. E.g. there's a partial index expression enforcing field A = "abc" but you still need to include field A in the index for the planner to pick it.

   Suggested indexes
   - Currently it will suggest indexes that can't be created, such as with multiple array fields.
   -- This should be detectable before suggesting an index.
   -- Highlight array fields in the suggested index
   - Include partial index expressions
   - Make more than one suggestion for queries

   Trying to create an index that contains multiple array fields (for some documents being indexed) won't fail until it hits one such document.
   - Pre-parse to first confirm the fields being indexed don't include more than 1 array for the index?
   - Pre-parse and inform the user if any of the fields… 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  ·  Indexes  ·  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. $group all fields

   $group should have the ability to allow specifying all fields in a document (without explicitly defining them all, which can lead to duplicating dozens of lines just to do "key: $first")

   This will help users that use $unwind and then want to $group the results without having to do a subsequent $lookup and $mergeObjects (or similar) to get the final document structure they're looking for.

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

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

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

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

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

15. Flatten arrays in group stage

    Have group operators to flatten document arrays into a single one with or without repeated elements.
    So ->
    doc1 = {arr: [1,2,3,4], gr: "group"}, doc2 = {arr: [5, 6, 7, 8], gr: "group"}
    {$group: {id: "$gr", arrays: {$***: "$arr"} } }
    =>
    {id: "gr", arrays: [1, 2, 3, 4, 5, 6, 7, 8]}

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

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

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

19. Cascading delete for DBRefs

    Since transactions have been added in 2018, which work across collections (https://www.mongodb.com/docs/manual/core/transactions/) and across shards (https://www.mongodb.com/docs/manual/core/transactions-sharded-clusters/), shouldn't cascading deletes be possible now? I only worked with sql transactions in the past, but my intuition would be that it should be fairly easy to do this in a client:

    1. start a transaction
    2. fetch document
    3. look for dbref fields
    4. fetch those docs
    5. continue at 2 until all docs have been found, stopping at branches when a doc has already been fetched
    6. go back in reverse and delete all of them
    7. commit transaction

    If this is possible to do in a client, it should be possible to do on the server as well, shouldn't it?

    Old and possibly outdated feature request: https://jira.mongodb.org/browse/SERVER-1298?signupSource=Account

    Since transactions have been added in 2018, which work across collections (https://www.mongodb.com/docs/manual/core/transactions/) and across shards (https://www.mongodb.com/docs/manual/core/transactions-sharded-clusters/), shouldn't cascading deletes be possible now? I only worked with sql transactions in the past, but my intuition would be that it should be fairly easy to do this in a client:

    1. start a transaction
    2. fetch document
    3. look for dbref fields
    4. fetch those docs
    5. continue at 2 until all docs have been found, stopping at branches when a doc has already been fetched
    6. go back in reverse and delete all of them
    7. commit transaction

    If this is possible to do… 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  ·  Transactions  ·  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. 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