325 results found

1. Allow Pinning Query Plan Cache Key to a Fixed Plan for a Given Query Shape Hash

   Allow Pinning Query Plan Cache Key to a Fixed Plan for a Given Query Shape Hash

   n MongoDB 8.0, the new setQuerySettings command allows administrators to enforce index hints and other behavior based on the query shape hash. This gives users partial control over query plan selection.

   However, the current implementation still allows the optimizer to re-evaluate multiple plans under certain conditions (e.g., plan cache eviction, plan ranking strategy). Additionally, the planCacheKey, which is the actual determinant for plan reuse, is generated based on more granular factors than the query shape hash (e.g., sort, collation, or exact index hint details).

   This FR proposes an extension to the query settings system to allow a user to pin a planCacheKey to a specific query shape hash, effectively enabling full plan determinism.

   Allow Pinning Query Plan Cache Key to a Fixed Plan for a Given Query Shape Hash

   n MongoDB 8.0, the new setQuerySettings command allows administrators to enforce index hints and other behavior based on the query shape hash. This gives users partial control over query plan selection.

   However, the current implementation still allows the optimizer to re-evaluate multiple plans under certain conditions (e.g., plan cache eviction, plan ranking strategy). Additionally, the planCacheKey, which is the actual determinant for plan reuse, is generated based on more granular factors than the query shape hash (e.g., sort, collation, or exact index hint details).

   … more

   • 

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

   Submit Rating

2. Add Option to Disable Specific Metric Groups in FTDC

   https://jira.mongodb.org/browse/SERVER-103431

   This is a feature request (not a bug) to enhance FTDC by allowing users to disable the collection of specific groups of metrics.

   Currently, FTDC collects a wide array of metrics including systemMetrics, which may contain data not always needed (e.g., disk stats from mount points that are irrelevant to the workload). This can generate unnecessary overhead or clutter when analyzing diagnostic data.

   Proposed Enhancement:{}

   Introduce support in FTDC for selectively disabling or adjusting the collection interval of particular groups of metrics, such as:

   systemMetrics
   serverStatus.connections
   Other major metric groups (as applicable)

   This filtering should ideally support:

   Disabling collection for a whole group (e.g., systemMetrics)
   Optionally: Changing the collection interval for specific groups

   Example Use Case:{}

   A user may not want to collect disk statistics from certain mount points (e.g., ephemeral or backup drives), and would prefer to disable this group entirely to reduce storage, analysis noise, or system impact.

   Sample Metrics (to illustrate the current output):

   systemMetrics.disks.sdk.readtimems;3812559;...
   systemMetrics.disks.sdk.writes;299070;...
   systemMetrics.disks.sdk.writesmerged;3663;...
   systemMetrics.disks.sdk.writesectors;196491030;...
   serverStatus.connections.current;21278;...
   serverStatus.connections.available;29922;...
   serverStatus.connections.totalCreated;6242624;...

   Motivation:{}

   Reduce data collection/storage footprint
   Focus only on relevant metrics
   Minimize noise during diagnostics and analysis
   Improve customization for performance-sensitive deployments
   Acceptance Criteria:{}

   Option exists (e.g., via config or command-line flag) to disable collection of specific metric groups
   Documentation updated to reflect new configuration capability
   FTDC output respects group disabling (no partial data)
   Optional: Allow adjusting collection intervals per metric group

   https://jira.mongodb.org/browse/SERVER-103431

   This is a feature request (not a bug) to enhance FTDC by allowing users to disable the collection of specific groups of metrics.

   Currently, FTDC collects a wide array of metrics including systemMetrics, which may contain data not always needed (e.g., disk stats from mount points that are irrelevant to the workload). This can generate unnecessary overhead or clutter when analyzing diagnostic data.

   Proposed Enhancement:{}

   Introduce support in FTDC for selectively disabling or adjusting the collection interval of particular groups of metrics, such as:

   systemMetrics
   serverStatus.connections
   Other major metric groups (as applicable)

   This filtering should ideally support:

   Disabling collection… more

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Native Support for Date-Only and Time-Only Field Types

   Summary

   MongoDB currently lacks native field types for date-only (e.g., 2025-05-28) and time-only (e.g., 13:45:00) values. This results in frequent developer confusion, incorrect behavior around time zones, wasted storage, and the need for error-prone workarounds in application code. Other modern databases and languages offer dedicated types for these partial temporal values — MongoDB should as well.

   ---

   Problems

   1. Timezone Shifts and Incorrect Behavior

   MongoDB’s Date BSON type stores full datetime values in UTC. If a developer stores a date-only value like 2025-06-01T00:00:00.000Z, clients in a negative timezone (e.g., UTC-6) will see 2025-05-31 — a different day altogether.

   Similarly, storing a time-only value (e.g., 13:30) requires embedding it in an arbitrary full datetime like 1970-01-01T13:30:00Z, which:

   • Is misleading (why that date?),
   • Can shift time unintentionally due to DST or timezone assumptions, and
   • Makes queries like "before 14:00" more complex and error-prone.

   2. Inadequate Workarounds for Time-Only Data

   Since MongoDB has no time type, developers use strings ("13:45"), integers (1345), or embed the time in a dummy date. All of these introduce serious issues:

   • Loss of type safety and query power (can’t use $gte, $lt with strings consistently)
   • Sorting bugs (e.g., "9:00" comes after "10:00" lexically)
   • Poor index support (no efficient numeric range queries on strings)
   • Manual parsing and validation burden in every consuming app
   • Data inconsistency when different developers or services choose different formats

   3. Increased Storage and Reduced Clarity

   Using full datetime objects when only a date or time is needed increases document size unnecessarily. This reduces performance in large collections and makes the intent of stored data unclear to developers or downstream systems.

   4. Developer Frustration and Compatibility Issues

   MongoDB’s close ties with JavaScript (via Node.js and Mongo Shell) make this particularly painful. JavaScript’s native Date object is already UTC-based and lossy for partial values. This forces developers to use libraries like dayjs, luxon, or string manipulations — none of which are consistent, built-in, or portable.

   ---

   Comparisons with Other Systems

   Many modern databases and languages already support this separation of concerns:

   PostgreSQL

   • Date-only Support: DATE
   • Time-only Support: TIME

   MySQL

   • Date-only Support: DATE
   • Time-only Support: TIME

   Python

   • Date-only Support: datetime.date
   • Time-only Support: datetime.time

   Java

   • Date-only Support: LocalDate
   • Time-only Support: LocalTime

   C# (.NET 6+)

   • Date-only Support: DateOnly
   • Time-only Support: TimeOnly

   JavaScript

   • Date-only Support: Temporal.PlainDate (Stage 3+)
   • Time-only Support: Temporal.PlainTime (Stage 3+)

   In particular, JavaScript’s Temporal API, now available in Firefox 139+, introduces Temporal.PlainDate and Temporal.PlainTime types for exactly these use cases — acknowledging this long-standing need in date/time semantics.

   Lack of Native Support in Other NoSQL Databases

   Even among specialized or enterprise-grade NoSQL databases, there is no native support for date-only or time-only types. Databases like Cassandra, Cosmos DB, RavenDB, and time-series databases such as InfluxDB all rely on full datetime formats or ISO 8601 strings for temporal data. This absence highlights a significant and persistent limitation across the NoSQL ecosystem. MongoDB has the opportunity to lead by addressing a gap that even its most capable peers have left unresolved — improving clarity, precision, and developer experience for a wide range of common use cases that don’t require full datetime semantics.

   ---

   Proposed Solution

   Introduce two new BSON types (and corresponding schema support):

   • DateOnly: Stores just a calendar date (e.g., 2025-06-01) with no timezone or time portion.
   • TimeOnly: Stores only the time of day (e.g., 13:45:00), ideally with optional milliseconds support.

   These types should:

   • Be timezone-agnostic
   • Support $gte, $lt, sorting, and indexing
   • Reduce document size when storing partial date/time values
   • Eliminate developer confusion and DST-related bugs
   • Improve integration with modern languages and libraries

   ---

   Use Cases

   • Date-Only:

     • Birthdays
     • Check-in/check-out dates
     • Holidays and recurring calendar events
     • Scheduling rules (e.g., "every Monday starting June 1")

   • Time-Only:

     • Store hours, business open/close times
     • Reminders or recurring alarms
     • Event scheduling templates ("Start at 14:00 every day")
     • Time-based access control

   Summary

   MongoDB currently lacks native field types for date-only (e.g., 2025-05-28) and time-only (e.g., 13:45:00) values. This results in frequent developer confusion, incorrect behavior around time zones, wasted storage, and the need for error-prone workarounds in application code. Other modern databases and languages offer dedicated types for these partial temporal values — MongoDB should as well.

   ---

   Problems

   1. Timezone Shifts and Incorrect Behavior

   MongoDB’s Date BSON type stores full datetime values in UTC. If a developer stores a date-only value like 2025-06-01T00:00:00.000Z, clients in a negative timezone (e.g., UTC-6) will see 2025-05-31 — a different day altogether.

   … 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

   Submit Rating

4. Implement a $hash operator for queries

   Current State:

   MongoDB currently lacks a native $hash operator in the aggregation/query language. While certain helpers like convertShardKeyToHashed or $toHashedIndexKey exist, they are limited in scope:

   • Not available as true query operators (e.g., inaccessible from MongoDB drivers).
   • Return Long values, which aren’t suitable for use cases like generating ObjectId-compatible hashes.
   • Not guaranteed to be stable across versions — limiting their use in persisted or version-sensitive scenarios.
   • Lack of flexibility in algorithm choice (e.g., MD5 only).

   The deprecation of $function further limits users’ ability to implement custom hashing via JS.

   ---

   Impact:

   Developers working with large datasets (dozens of GB) are unable to:

   • Perform deterministic hashing inside MongoDB queries/aggregations.
   • Use hash values as _id or compact document identifiers for deduplication, fingerprinting, or efficient lookups.
   • Build predictable, cross-version-stable hashes within MQL.
   • Avoid extra client-side computation or complex workarounds involving bitwise operations, slow modulo arithmetic, or full client-side aggregation to generate a hash.

   Additionally, non-driver-accessible helpers lead to more application logic overhead and additional round-trips to the database, hurting latency and performance.

   ---

   Potential Future State:

   Introduce a first-class $hash operator in the MongoDB query and aggregation language:

   {
     $hash: {
       algorithm: "SHA384",  // e.g., SHA256, SHA512, etc.
       data: <expression>,
       // Optional: key (for HMAC support in the future)
     }
   }
   

   • Returns a hexadecimal string (or binary, or ObjectId-compatible format).
   • Deterministic and version-stable.
   • Accepts MQL expressions for the input.
   • Could include support for standard NIST algorithms (see: https://csrc.nist.gov/projects/hash-functions).

   Initial implementation could focus on non-HMAC hashes only to reduce scope.

   ---

   Additional Info or Links:

   • Use case: compact storage of hash-based _ids for large datasets.
   • Common workaround (not ideal): https://stackoverflow.com/questions/67426169/how-do-you-convert-a-hexadecimal-string-into-a-number-in-mongodb
   • NIST-approved algorithms list: https://csrc.nist.gov/projects/hash-functions
   • Workarounds using convertShardKeyToHashed introduce compatibility risks, limited hash size (64-bit), and type conversion issues (e.g., can’t easily convert Long to hex string/ObjectId).
   • Customer is open to discussing use cases in more depth.

   Current State:

   MongoDB currently lacks a native $hash operator in the aggregation/query language. While certain helpers like convertShardKeyToHashed or $toHashedIndexKey exist, they are limited in scope:

   • Not available as true query operators (e.g., inaccessible from MongoDB drivers).
   • Return Long values, which aren’t suitable for use cases like generating ObjectId-compatible hashes.
   • Not guaranteed to be stable across versions — limiting their use in persisted or version-sensitive scenarios.
   • Lack of flexibility in algorithm choice (e.g., MD5 only).

   The deprecation of $function further limits users’ ability to implement custom hashing via JS.

   ---

   Impact:

   Developers working with large datasets (dozens of GB) are… 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  ·  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

   Submit Rating

5. Dont Deprecate LDAP in future Major Version releases.

   we have everything configured with LDAP including Ops manager agents/bind id's/DB ID's etc. We have so much dependency on LDAP which helps us in many ways including rotation of passwords in CyberArk, No dependency of Single passwords etc.
   Kindly help not to deprecate LDAP features.

   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

   Submit Rating

6. Per-Shard Change Stream and Triggers to improve scalable/performance/resilience

   In our geo-sharded cluster, we use Change Streams and Atlas Triggers.
   Most of our pipelines include a match for the shard key - so we can process the data in the same region where the data resides.

   However, due to the design of change streams with sharded clusters, the change streams are collected from all shards even if the pipeline matches only a specific match. In addition, if a shard has no changes to report, mongos waits up to 10 seconds (by default) before responding to the driver. This makes the data processing too slow.

   This suggestion would also greatly improve scalable, performance and resilience of a MongoBD Global Cluster by not waisting resources on unrelated shards.

   In our geo-sharded cluster, we use Change Streams and Atlas Triggers.
   Most of our pipelines include a match for the shard key - so we can process the data in the same region where the data resides.

   However, due to the design of change streams with sharded clusters, the change streams are collected from all shards even if the pipeline matches only a specific match. In addition, if a shard has no changes to report, mongos waits up to 10 seconds (by default) before responding to the driver. This makes the data processing too slow.

   This suggestion would also greatly… 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

   Submit Rating

7. Maintain database ID/Password profile inside database

   Requirement is to maintain database id/passwords with standard details inside database like (Lastlogin date/ passwordchangedate) and control of passwords related how many failedloginattempts/passwordlifetime/passwordcomplexity/passwordlocktime/passwordreusemax etc

   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

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

   Submit Rating

8. Validation should support default values

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

   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

   Submit Rating

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

10. Decouple "insert" privilege from implicit collection creation

    MongoDB currently allows a user with the insert privilege on a database to implicitly create a new collection by inserting into it — even if the user lacks the createCollection privilege. This behavior makes it difficult to enforce strict access control policies, particularly in security-conscious or regulated environments.

    In contrast, traditional SQL databases like PostgreSQL and MySQL enforce a clear separation:

    The INSERT privilege applies only to existing tables.
    A separate CREATE privilege is required to define new tables.

    We request that MongoDB introduce the ability to decouple insert from implicit collection creation, such as:

    A new action like "insertExistingOnly", or
    A configurable server or role-level option to disallow implicit collection creation via insert.

    This would help:
    1. Enforce stricter security models.
    2. Align with least-privilege principles.
    3. Reduce the risk of accidental or unauthorized schema drift.

    Use Case:
    In a multi-tenant or production environment, we want to allow users or apps to insert into specific collections but prevent them from creating new collections, whether intentionally or accidentally.

    Thank you for considering this request to improve MongoDB's privilege granularity and security controls.

    MongoDB currently allows a user with the insert privilege on a database to implicitly create a new collection by inserting into it — even if the user lacks the createCollection privilege. This behavior makes it difficult to enforce strict access control policies, particularly in security-conscious or regulated environments.

    In contrast, traditional SQL databases like PostgreSQL and MySQL enforce a clear separation:

    The INSERT privilege applies only to existing tables.
    A separate CREATE privilege is required to define new tables.

    We request that MongoDB introduce the ability to decouple insert from implicit collection creation, such as:

    A new action like "insertExistingOnly",… 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  ·  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

    Submit Rating

11. Coordinate Releasing Better

    When Mongo releases a new version, the downloads, release notes, and version selection in the support portal are never in sync and sometimes out of sync for weeks.

    An example right now is 7.0.20. It has been out for a while. If I update via my OS's package manager, I get 7.0.20. Is 7.0.20 in the release archive download page? No. Does it have any published release notes? No. Is it selectable in the Versions list at support.mongodb.com? No. In fact, 7.0.19 is still not selectable there.

    This is very frustrating and causes a lot of workflow/process issues. For example, Queryable Backups is broken on Amazon Linux 2023, so part of our documented process is "find the latest version and manually put it on the backup daemon box before running a queryable backup". Ops Manager will try to download 7.0.20 and fail, even though that's the latest version. How do we know it's going to download 7.0.20? We don't. If we check the Releases page, we think we need to download 7.0.19. The solution is to start a backup, watch it fail, see the version it tried to download, and correct it manually.

    Please coordinate your release process better. Thank you.

    When Mongo releases a new version, the downloads, release notes, and version selection in the support portal are never in sync and sometimes out of sync for weeks.

    An example right now is 7.0.20. It has been out for a while. If I update via my OS's package manager, I get 7.0.20. Is 7.0.20 in the release archive download page? No. Does it have any published release notes? No. Is it selectable in the Versions list at support.mongodb.com? No. In fact, 7.0.19 is still not selectable there.

    This is very frustrating and causes a lot of workflow/process issues. For example,… 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  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Allow the ability when NVME cluster to autoscale up based on CPU and Memory

    To provide autoscaling capability for MongoDB NVME clusters based on CPU utilization and memory metrics. This feature would automatically provision additional resources when predefined thresholds are reached, ensuring optimal performance during usage spikes without manual intervention.

    Currently, MongoDB Atlas NVME-based clusters require manual vertical scaling, which leads to:
    - Performance degradation during unexpected high-load periods
    - Inefficient resource allocation requiring constant monitoring
    - Potential application downtime during scaling operations
    - DevOps overhead for continuous capacity planning

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

    Submit Rating

13. mongodump - add support for nsInclude/nsExclude

    Currently mongodump supports the excludeCollection/includeCollection options but this requires the use of the --db option. It would be useful if mongodump was able to dump all databases, as it does by default, but also be able to specify a collection or collections not to dump.

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

    Submit Rating

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

15. Add support for all type of joins like Postgres has and improve performance

    $lookup is a performance killer. Joins are crucial parts in every OLTP system. $lookup is the equivalent to join in SQL, however $lookup is slow, doesn't support hash joins or other efficient join algorithm implemented in Postgres for example.

    Seems that if mongo won't add support, their DB puts behind Postgres.

    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

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

    Submit Rating

16. Leveraging Group By/Distinct Query to use regular Index

    When using Group By or Distinct queries on database, provide the ability to leverage existing index

    i.e these queries today will miss using existing index

    db.collection.distinct("field")

    db.collection.aggregate([
    { $group: { _id: "$category", count: { $sum: 1 } } }
    ])

    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

    Submit Rating

17. Disallow new connections that don't specify an appName field

    Currently as a DBA it's sometimes hard to identify which service is causing load on a shared cluster/database. Some people connect for adhoc workloads but don't specify an appName making it hard to track back to the owner. It would be useful to require appName for connections to a cluster to enforce this behavior.

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

    Submit Rating

18. MongoDB should have a database backup system commit base for large self-management databases, like git commit.

    There is already a mongodb backup tool mongodump but it is not a good solution for backing up large databases. We thought of making a CMS Platform with mongodb. Billions of websites can be created there. For such a large platform, the mongodump backup tool does not seem sufficient.

    We want a solution where Mongodb will manage a different backup directory their data will not be deleted even run the delete command. like blockchain. If we run the delete command it will delete the data from the main database but the secondary backup database will declare it as a delete instance. It will create an encrypted snapshot of all data changes every 30 minutes so that data from that time can be retrieved as a Git commit

    I don't know if this is possible. If it is possible, it would be possible to backup a large database to an encrypted file and it would be much more reliable. This way, if our main database gets corrupted, we can get back the data at any point in time.

    There is already a mongodb backup tool mongodump but it is not a good solution for backing up large databases. We thought of making a CMS Platform with mongodb. Billions of websites can be created there. For such a large platform, the mongodump backup tool does not seem sufficient.

    We want a solution where Mongodb will manage a different backup directory their data will not be deleted even run the delete command. like blockchain. If we run the delete command it will delete the data from the main database but the secondary backup database will declare it as a delete… 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

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

    Submit Rating

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

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