324 results found

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

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

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

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

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

   Submit Rating

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

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

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Display Recovery time during restore process.

   Team,

   Currently Mongo DB restoration process not giving any recovery time estimate when restore process start and because of that we are not able to plan time window for other critical process to start which is depend on restore and not able to communicate exact time when system will be available.

   Please include this feature in upcoming release.

   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

   Submit Rating

6. Support readOnly in Json Schema Validation

   Support the readOnly property for json schema validation to make certain fields immutable (or the entire document) after creation.

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

7. Enforced Password Complexity

   Please allow for the enforcement of password complexity:
   - Setting a password policy that restricts users to a certain level of complexity (e.g 10 chars with special characters)

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

8. Make IAM database user authentication compatible with AWS SSO

   We are in the process of implementing AWS SSO across our Organisation and wanted to tie this in with mongodb-aws for database authentication.
   Unfortunately we have been informed the 2 services are not compatible.

   This would be a really useful add on to improve management of our systems.

   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

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

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Include schema validation events in changestream payload

   let's say my document has JSON schema validation like:

   {
     $jsonSchema: {
       properties: {
         phone: {
           bsonType: 'string'
         }
       }
     }
   }
   

   and the validation action is set to "warning", if I do a command like: db.test.insert({"phone":1}), I would like the warning message to be included in my change stream.

   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  ·  Change Streams  ·  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. Data masking policy

    Implement Data masking similar to Schema Validation in Mongo so that customer can define a server-side data masking policy to mask the results of a query and a new role which will give explicit permission to users for reading unmasked data

    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  ·  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. Extend db.collection.distinct() to work with multiple fields in a compound key

    Currently the distinct() command finds the unique set of values for a SINGLE specified field across a collection or view. For example:
    db.staff.distinct("last_name" )

    If there is an index on the lastname field, the DISTINCTSCAN plan can use that index and the operation is very fast.

    To find the unique values for a set of more than one fields, the $group aggregation stage has to be used like this:
    db.staff.aggregate([
    {$group: {id: {FName: "$firstname", LName: "$last_name"}} ]);

    This operation does not really need the $group functionality, as it is not calculating a sum/min/max/average/etc value using the accumulator operators. It also runs much more slowly than a DISTICT_SCAN.

    The ask here is to allow distinct() to be run over a set of fields, and use DISTINCT_SCAN if there is an index over the same fields.

    Currently the distinct() command finds the unique set of values for a SINGLE specified field across a collection or view. For example:
    db.staff.distinct("last_name" )

    If there is an index on the lastname field, the DISTINCTSCAN plan can use that index and the operation is very fast.

    To find the unique values for a set of more than one fields, the $group aggregation stage has to be used like this:
    db.staff.aggregate([
    {$group: {id: {FName: "$firstname", LName: "$last_name"}} ]);

    This operation does not really need the $group functionality, as it is not calculating a sum/min/max/average/etc value using the… 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

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. wired

    wiredTiger open files usage

    Currently WT uses a file per collection and index, leading in some scenarios to extremely high number of open files/dhandles.

    Is there any plan to support one file/dhandle per database?

    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  ·  Storage (Wired Tiger)  ·  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. Allow multiple text indexes per collection

    MongoDb only allow one text index by collection, in contrast of other index types.

    This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

    Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick, easy, and efficient solution for many of these scenarios.
     
    This would be a good feature for mongodb :)

    MongoDb only allow one text index by collection, in contrast of other index types.

    This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

    Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick,… 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

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

    Submit Rating

14. Ability to enable collection name enforcement

    Currently if you perform a find or other operation, and you have a typo in your collection name, the operation will execute successfully and there is no indication that the collection you are operating on doesn't exist. It would be handy if there were some sort of session variable that could be set that tells the engine, to return an error if the collection being operated on does not exist. For example, lets say we have a collection named "myCollection". If I issue a find with a typo in the collection name from the shell like:

    db.myCollectio.find();

    This will successfully run and return no records even though "myCollectio" doesn't
    exist. If there were some way to say, I want to enforce and check that the collection actually exists as part of the collection operation such that if the above command were issues, and error would be thrownindicating "myCollectio" does not exist.

    This would save a lot of troubleshooting headaches in that people don't always realize there is a typo in their collection name.

    I'm not sure if this would be a database engine modification or a shell modification.

    Currently if you perform a find or other operation, and you have a typo in your collection name, the operation will execute successfully and there is no indication that the collection you are operating on doesn't exist. It would be handy if there were some sort of session variable that could be set that tells the engine, to return an error if the collection being operated on does not exist. For example, lets say we have a collection named "myCollection". If I issue a find with a typo in the collection name from the shell like:

    db.myCollectio.find();

    This will successfully… 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  ·  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. Improve the election process to consider node reachability

    Consider both new and existing sockets to be utilized in order to make more realistic observations about cluster health during an election to avoid for example DNS related issues which would make a node unreachable for new connections.

    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  ·  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. Upgrade Advisor

    Similar to Microsoft's SQL Server Upgrade Advisor application, generate a report (from Ops Manager for example) identifying issues to fix before or after an upgrade from one major version to another.

    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  ·  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. MongoDB 4.2 Distributed Transaction with Arbiter

    Hello.
    We are preparing to introduce MongoDB 4.2 and expect distributed transaction function.

    I read document which arbiter don't be member when use distributed transaction.

    https://docs.mongodb.com/manual/core/transactions/index.html#arbiters

    PSA can do that, but it's weird that it doesn't even work out to PSSA.

    It usually operates as a PSS from an operating point of view, but can temporarily become a PSA in the event of equipment problems.

    Why should there be no Arbiter in the Shard to use Distributed Transaction?
    I can not understand restriction.

    Can you tell me technical reason for not being able to support Distributed Transaction with Arbiter?
    Do you have plans to improve in the next version?

    Hello.
    We are preparing to introduce MongoDB 4.2 and expect distributed transaction function.

    I read document which arbiter don't be member when use distributed transaction.

    https://docs.mongodb.com/manual/core/transactions/index.html#arbiters

    PSA can do that, but it's weird that it doesn't even work out to PSSA.

    It usually operates as a PSS from an operating point of view, but can temporarily become a PSA in the event of equipment problems.

    Why should there be no Arbiter in the Shard to use Distributed Transaction?
    I can not understand restriction.

    Can you tell me technical reason for not being able to support Distributed Transaction with Arbiter?
    Do… 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

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

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

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

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