This is your weekly summary of Compose news for those changes and updates which can make your life easier. In this edition, we look at "soft deprovisioning" - a new safety feature in Compose and take a look back at the week in Compose Articles.

Deprovisioning and you

TL;DR: If you delete a database deployment and then try and then create a new deployment with the same name, the Compose platform will refuse to create it for 24 hours after the deletion.

Deleting a Compose database is relatively simple for users. All it takes is an admin account, a password to reauthenticate with and the ability to type in to name of the database deployment you want to delete. We call this process deprovisioning. It's all part of the lifecycle of databases on Compose as we make it easy to create, use and delete databases whenever you need them.

The thing about deprovisioning

In the past, our automated systems have immediatly swooped in and removed all the servers, portals, addons and files, leaving only the previous backups. We are changing that now because we've found that users have, for whatever reason, accidentally deleted their database deployments and then, realising their error, needed their databases back as soon as possible.

Although restoring from a backup is possible, for large databases that process can take some hours. Depending on how old the backup is, it also may not match the final state of the database when it was shut down.

Experience shows us accidental deprovisioning usually happens with active databases. The activity in that database - from the last backup right up to the shutdown - won't be captured anywhere and so wouldn't be restorable either. That means there's a bigger hole in the data when it is restored.

Enter soft deprovisioning

We wanted a better way to care for your databases and your data, especially when there's a chance deprovisioning was a mistake. That's why we have introduced "soft deprovisioning".

Now, when you delete a database deployment it's actually placed in a state of suspended animation, disconnected, isolated and with billing turned off. It will remain that way for 24 hours at which point the normal deprovisioning process kicks back in and the automated systems swoop in to delete the component parts of the deployment.

From a user's point of view, it'll still look like it has been deleted. The only exception to that is if you try and create a new database deployment with the same name within that 24 hours, you'll be refused as the database deployment records are still in place until the final deletion. We think this small inconvinience is worth it though; deployment names are, literally, just labels.

In return, when the worst happens and you accidentally delete your production database, as long as you are inside that 24 hour window, support will be able to pull your database out of deep sleep and have it up and running in no time. We think that's something everyone benefits from.

Compose Articles

Last weeks Compose Articles included a look at how we architect Compose databases and all the latest news in NewsBits:

• How Compose does... is a new occasional series where we'll be looking at the aspects of Compose databases, how they are configured and how this matters to you. In How Compose does... MongoDB we take a tour through the various configurations of MongoDB, how we arrived at the one we deploy to customers today and how it works for users and applications.

• Last week's NewsBits covered the slew of database upates coming for PostgreSQL, RabbitMQ, etcd and Scylla from their developers, a look at CloudEvents, Firefox 60 and enterprises, new styles of Malware and welcoming in Rust 1.26.

That's it for this week's Noteworthy at Compose. Onwards to next week!

Read more articles about Compose databases - use our Curated Collections Guide for articles on each database type. If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at articles@compose.com. We're happy to hear from you.