Managed databases
A managed database is one the platform runs, backs and bills for you, instead of one you declare as a service in your own compose file. It belongs to the organization rather than to an application, so the same database can back a web app and its worker, and it survives every deploy, rollback and teardown those applications go through.
Find them under an organization → Managed services. Buckets live on the same page and follow the same lifecycle; everything below applies to both, except where it talks about roles and SQL.
Why it is not just a container you run yourself
You can put Postgres in your own compose file, and nothing stops you. The difference is what happens when the container stops.
| Your own compose service | A managed database | |
|---|---|---|
| Where the data lives | Inside the container's filesystem | On the platform's engine, outside anything your deploy replaces |
| Surviving a redeploy | A rolling update replaces the container | Untouched — it is not part of your stack |
| Surviving a teardown | Gone with the stack (Lifecycles) | Untouched, and still there when you deploy again |
| Running out of credit | Torn down with everything else, after a grace period | Suspended — logins refused, data kept |
| What you are billed | Container-seconds, like any other service | Storage by the GiB-month, plus what your queries make the engine do |
Creating one
On the organization's Managed services page, pick an engine, give it a name and press Create. The name is yours and only has to be unique within the organization — lowercase letters, digits and hyphens, up to 63 characters.
From the CLI, the same thing:
sc service create postgres:17 hearth
The first database on a given engine version waits; every one after it does not. An engine nobody has used yet is a catalogue entry rather than a running thing, so the first request stands one up — a container image to pull and a database server to start, which is a minute or two. The page tells you when this is what you are waiting for. Every subsequent database on that same engine is a handful of statements and lands in seconds.
Once it is Available the page shows you the connection details.
The states it moves through
The state is the chip beside the name, on both the list and the detail page.
| State | What it means |
|---|---|
| Queued | Accepted, waiting for an engine to be ready for it |
| Creating | The role and the database are being made |
| Available | Working. The only state that accepts logins |
| Suspended | Off, but kept. Logins are refused; the data is untouched, and still billed for its storage |
| Dropping | The irreversible delete is running |
| Dropped | Gone. The row stays so the record of what it cost survives |
| Failed | The engine refused something. The reason is on the detail page |
Suspension: off, but not gone
Suspending is the platform's word for "off", and it is deliberately not deletion. Logins stop; every byte stays exactly where it was, and keeps being billed at the storage rate. It is one reversible statement at the engine rather than anything being destroyed, which is why it is what a zero balance does instead of the grace-period teardown an application gets.
Three things suspend a database, and the chip tells you which — because the thing you have to do about it differs:
| Chip | Why | What clears it |
|---|---|---|
| Suspended | You or an operator asked for it | Resume it. Nothing clears this on its own |
| Suspended · Credit exhausted | The organization's balance reached zero | Top up. It resumes on its own |
| Suspended · Over quota | It is past its storage quota | Delete data, or ask us to raise the quota. A top-up will not resume it |
Two rules about coming back that are worth knowing before you need them:
- A top-up only resumes what the platform suspended. If you or an operator switched a database off deliberately, the ledger moving does not switch it back on — reversing somebody's decision because a payment landed would be the wrong behaviour.
- Credit and quota are independent, and both have to clear. A database that is out of credit and over quota stays suspended after a top-up, because the second reason is still true.
Deleting one, and the seven days after
Deleting closes the door and starts a clock; it does not destroy anything yet. The role is locked so nothing can keep writing to a database its owner believes is gone, the entry disappears from your listings, and the data itself survives for seven days before the irreversible half runs and the state becomes Dropped.
sc service destroy hearth
A database an application is still bound to is refused. Unbinding has a
visible consequence — the application loses its connection details on its next
deploy — and doing it silently as a side effect of a delete is how a production
database gets destroyed by someone tidying up. --force is the way through, so
the destructive path exists but has to be asked for.
Changed your mind inside the seven days? The data is still there, but undoing a delete is not something you can do yourself today — there is no button and no CLI verb for it. Ask support while the window is open. Once it reads Dropped, it is gone.
Binding it to an application
A database is no use to an application that cannot reach it. Binding is what connects the two, and it is per-application:
sc service bind hearth --app web
sc service unbind hearth --app web
The application's own page lists what it is bound to, and the database's detail page has a Bound to section listing it from the other side. On the next deploy the application picks up its connection details as environment variables, and the platform puts a small connection proxy alongside your services so your application talks to something on its own network rather than reaching across the platform's.
Unbinding takes effect on the next deploy, not immediately — a running container keeps the environment it started with.
What it costs
Two meters, both hourly, both on the same ledger as everything else (Billing):
| Meter | Charged on |
|---|---|
| Storage | How much the database is holding, by the GiB-month |
| Engine load | How much work your queries make the shared engine do |
Storage is shown in GiB on the page whatever the number, rather than rounded to whichever unit fits, because GiB-months is what the invoice is in — a 40 MiB database displayed as "40 MiB" would need converting in your head before it could be compared to a bill.
A suspended database still costs storage. That is the trade suspension makes: the data is kept, so keeping it is charged for. A database you genuinely do not want any more should be deleted, not left suspended.
Where the states come from
The state on the page is the platform's own record of the database, not a guess from probing it. If one is stuck in Creating, or reads Failed, the detail page carries the reason the engine gave rather than a generic message — that text is the useful thing to quote if you ask us about it.
For how an application's own containers behave — which is a different lifecycle on a different clock — see Lifecycles.