What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

Certain use cases — audit logs, financial transaction ledgers, regulatory event trails, compliance records — require data that must never be modified or deleted after insertion. Today, MongoDB has no native mechanism to enforce write-once/append-only behavior at the collection level. The only options are application-level enforcement (which can be bypassed), or using $currentDate-style tricks with schema validation (which is brittle and doesn't prevent deletes). Any user or application with write permissions can update or delete documents, even in collections where that should never happen. This creates a compliance and data integrity gap for customers in regulated industries — fintech, healthcare, government — where immutability isn't just a nice-to-have but a regulatory requirement.

What would you like to see happen?

Describe the desired outcome or enhancement.

A collection-level option (e.g., immutable: true or writeMode: "insertOnly") that enforces append-only behavior at the storage/server level. Once set, the collection would only allow insert operations — all update, replaceOne, delete, findAndModify, and drop operations would be rejected by the server. Optionally, a TTL or retention policy could be paired with this so documents can expire automatically without manual deletes, supporting time-bound compliance windows. An admin-level override or migration path (like requiring a specific role to disable immutability) would make it operationally practical.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

Customers in fintech, crypto exchanges, and healthcare frequently ask how to guarantee audit trail integrity in MongoDB. Today we have to recommend application-level guardrails or suggest pairing MongoDB with a separate append-only store, which adds architectural complexity and pushes customers toward multi-database setups. Native immutability would make MongoDB a stronger single-platform choice for regulated workloads, reduce compliance risk for customers, and eliminate an objection that often comes up during architecture reviews against competitors that offer this natively (e.g., Amazon QLDB, Datomic, or even simple WORM storage at the object-store level).

What steps, if any, are you taking today to manage this problem?

The current workarounds are fragile and layered. Customers typically use a combination of: restrictive RBAC roles that remove update/delete privileges (but these can be overridden by admins), schema validation with updated_at checks to detect modifications (but this doesn't prevent deletes), change streams to audit post-facto modifications (reactive, not preventive), and application-level middleware that blocks update/delete calls (bypassable, not enforceable at the database layer). None of these provide true server-enforced immutability — they're all "best effort" and leave gaps that auditors flag during compliance reviews.