I would strongly, but kindly request this option to size down not be one. If it's a "one way street" for resizing, then a "wrong way" sign should be in place. This can be done by either putting up guardrails with restrictions on how resizing can be accomplished, or documenting and clearly displaying in the option to resize storage, a warning that downsizing a dbaas storage volume is inadvisable and can have adverse effects. 

This does 2 things. One, it gives the admin the understanding at that point in time they need to take action to resolve an issue that this is in fact a one-way street. And to be very certain, upsizing is the correct action they want to take, because going back/reverting is not really an option, and it will have a financial impact. This goes the same if a user chooses to auto-scale. Two, it provides critical information for an admin that is in a planning phase. In other words, I would know that when I'm designing an architecture that includes a dbaas, I need to take into consideration any actions, automated or manual, that would potentially resize the disk.

This Document (https://docs.digitalocean.com/products/databases/mysql/how-to/resize/) is incorrect in one statement I've found. It states, "To avoid data loss, you cannot decrease the size of database clusters." However, one can actually do this to a limit. So for example, and I did actually test this, if my dbaas Storage range is 60 GiB - 120 GiB, and I increase it to 80 GB, it'll perform that operation and size up within a minute. If I then decided my 12 GB database doesn't have a need in the near future for 80 GB of disk space, it allows me to downsize it back to 60 GB. It doesn't allow me to go lower than that, but it does allow me to change and apply the size to 60 GB. This dose of course create a potential for data corruption and a failure to actually complete the resize process. Leaving it in a never ending loop as it attempts to complete a successful resize process.