Version-controlled databases are kind of DoltHub’s jam. One of the selling points of a version-controlled database is that it never loses anything. Every modification of your data can be committed and preserved forever.
In the past, there was one major gap in our primary database, Dolt: if you dropped a database, it was gone forever. We addressed that gap three years ago. Today, Dolt doesn’t actually delete the data when you drop a database. Instead, it moves the data to a special place and removes the database name from the list of databases. This means that if you accidentally drop a database, you can use the undrop operation to bring it back.
The typical option offered in this case is to restore from a backup. This assumes you have a backup and that the backup is recent enough to be useful. How recent is recent enough? Nightly backups mean you will, on average, lose 12 hours of data. Ugh. Not a great solution.
DumboDB, our MongoDB-compatible version-controlled database, has joined the undrop party! DumboDB now supports the dumboUndrop operation, which allows you to resurrect a dropped database. This means that if you accidentally drop a database in DumboDB, you can bring it back with ease: no data loss, no restoring from backups, and minimal downtime. Just a simple command to bring your database back to life. Let’s jump in!
Whoops!#
In MongoDB, dropping a database is a permanent operation. Once you drop a database, it’s gone forever. This is insanely easy to do:
use customers
db.dropDatabase()In a replicated environment, this operation is propagated to all nodes in the cluster. With lightning-quick efficiency, you lose everything. This is not to say that MongoDB is any worse than other databases. It’s just as easy to do this on most SQL databases: drop customers; - poof, gone.
Mongo does have a dropDatabase action that can be controlled through security settings to prevent everyone from being able to do this. In my experience, that’s the kind of permission configuration you discover in the postmortem after the database has been dropped. Fine-grained permissions are great, but for those in the audience who know that things like this get missed all too often, the dumboUndrop operation is a lifesaver.
dumboUndrop to the Rescue!#
OK, so say you’ve gotten yourself into this situation. You dropped the customers database and now you need it back. You can use the dumboUndrop operation to bring it back. The syntax is simple:
> use admin
switched to db admin
admin> db.runCommand({dumboUndrop: 1, name: "customers"})
{
undropped: 'customers',
dropId: '1783969394769945000',
ok: 1
}The first thing you’ll note is that this is an admin operation. We could say it’s for admins only, but the real reason is that the admin database is always present. If you’ve dropped your database, you obviously can’t execute commands against it. admin for the win. Worth noting: it’s impossible to drop the admin database, so it’s always there in your time of need.
Other Tricks of dumboUndrop#
The dumboUndrop operation will list all dropped databases if you don’t specify a name. This is useful if you have multiple dropped databases, some of which share the same name but were dropped at different times. The dropId is a unique identifier for each dropped database, so you can use it to specify which one you want to undrop.
admin> db.runCommand({dumboUndrop: 1})
{
dropped: [
{
name: 'customers',
dropId: '1783969724626290000',
droppedAt: ISODate('2026-07-13T19:08:44.626Z')
},
{
name: 'customers',
dropId: '1783969394769945000',
droppedAt: ISODate('2026-07-13T19:03:14.769Z')
}
],
ok: 1
}This shows that the customers database was dropped twice, within 5 minutes of each other. What an operational mess! By default, dumboUndrop will undrop the most recently dropped database with the specified name. In this case, if you determine that the older version is the one you want, you can use the dropId to specify which one you want to undrop.
admin> db.runCommand({dumboUndrop: 1, name: "customers", dropId: '1783969394769945000' })
{
undropped: 'customers',
dropId: '1783969394769945000',
ok: 1
}Finally, if you want to undrop a database to a different name, you can use the toDatabase option. This is useful if you want to use the data in the dropped database, but you don’t want to restore it to its original name (maybe you already restored it).
admin> db.runCommand({dumboUndrop: 1, name: "customers" , toDatabase: "alt_customers"})
{
undropped: 'alt_customers',
dropId: '1783969724626290000',
ok: 1
}Purging Dropped Databases#
Currently, DumboDB will purge your dropped databases after 30 days. This isn’t configurable (but could be if you asked for it). If you want to purge a dropped database before the 30 days are up, you can use the dumboUndrop operation for that as well.
There is an argument field, purgeMatching, which allows you to purge dropped databases from your disk. The input structure looks like this:
{
name: <database_name>, // required
dropId: <drop_id>, // optional
droppedBefore: <ISODate> // optional
}If you specify just the name, all dropped databases with that name will be purged. If you specify the dropId, only that specific dropped database will be purged. If you specify droppedBefore, all dropped databases with that name that were dropped before the specified date will be purged. dropId and droppedBefore are mutually exclusive, so you can only specify one of them.
The only required field is the name of the database. This will purge all dropped databases with the specified name:
admin> db.runCommand({dumboUndrop: 1, purgeMatching: {name: "customers"}})
{
purged: [
{
name: 'customers',
dropId: '1783969724626290000',
droppedAt: ISODate('2026-07-13T19:08:44.626Z')
},
{
name: 'customers',
dropId: '1783969394769945000',
droppedAt: ISODate('2026-07-13T19:03:14.769Z')
}
],
ok: 1
}
admin> db.runCommand({dumboUndrop: 1})
{ dropped: [], ok: 1 }If you want to limit the number of databases that are purged, provide the dropId or droppedBefore fields.
Conclusion#
DumboDB, along with its friends Dolt and Doltgres, is here to help you manage your data with confidence. With the dumboUndrop operation, you can rest easy knowing that even if you accidentally drop a database, you can bring it back with ease. No more restoring from backups, no more downtime, and no more lost data. Just a simple command to bring your database back to life.
Want to learn more about Dolt and Dumbo? Hop on our Discord to ask questions and nerd out about version-controlled databases!