Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Submitted
Created by Thomas van Vugt
Created on Aug 17, 2026

Drop logical (on-disk) database upon deletion of MongoDBUser resource (MongoDB Kubernetes Operator)

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.

Deletion of a MongoDBUser resource in the MongoDB Kubernetes Operator removes only the authentication identity: the user is removed from Ops Manager and authentication fails, but the logical database and all its data remain on disk, unchanged and fully readable by any privileged accessor. For decommissioning, tenant offboarding and data-cleanup obligations, we need the data associated with a deleted user/database to be removed, not merely its credentials revoked. Today there is no operator-supported, declarative way to achieve this.

What would you like to see happen?

Describe the desired outcome or enhancement.

An opt-in, declarative mechanism to drop the user's database when the MongoDBUser resource is deleted; for example a spec field such as cleanupPolicy: DropDatabase (or deletionPolicy), or a finalizer/lifecycle hook option that runs db.getSiblingDB(spec.db).dropDatabase() on deletion. Default behavior should stay unchanged (opt-in only), since a database may be shared with other users or applications.

Why is this important to you or your team?

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

We are an organization with data-minimization and retention obligations. Orphaned databases holding production data after the owning team's custom resource is deleted are both a data-retention and a data-exposure risk. We see MongoDB as an integral part of an application team's deployment, and the GitOps/declarative lifecycle the operator provides is broken when data removal requires manual admin intervention.

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

A manual, pre-deletion workflow: read and validate spec.db, confirm no other users or applications share the database, obtain stakeholder confirmation, run dropDatabase() with admin credentials, verify the database is absent, and only then delete the MongoDBUser resource. This is error-prone, unauditable, does not scale, and sits outside the CR lifecycle.