On Heroku, databases and dynos are completely distinct entities, each with their own payment plans.
When you set up a dyno and “add” a database, as most people do, it’s really easy to think that they are part of the same plan, and conclude that the “pro” or paid dyno is actually the combo of the dyno and database. They are not.
I understand why they did this, databases can be shared between applications, that’s handy, but this is a sharp edge.
The least they could have done is disconnect the database without deleting the data, so users would at least have a chance to make the decision to either delete or start paying.
This is something I've put into most workflows at $(WORKSPACE=/=heroku) that end up disabling a customers systems. It depends a bit on how hard we have to kill a system for various factors. But for the softest setting, we usually start pulling DNS or similar access configs for a minute, wait for a minute, disable for 2, wait for 2, ... and the 30 minutes never end.
This gets people on the phone with support quickly if they don't react to their account manager or mails. Like, we've had a possible security incident coming from a customer system and they didn't react - because they tried to hide their processes internally. Scream-Testing got us on calls with their InfoSec in a hurry.
On Heroku, databases and dynos are completely distinct entities, each with their own payment plans.
When you set up a dyno and “add” a database, as most people do, it’s really easy to think that they are part of the same plan, and conclude that the “pro” or paid dyno is actually the combo of the dyno and database. They are not.
I understand why they did this, databases can be shared between applications, that’s handy, but this is a sharp edge.