Guide

Database lifecycle

Layerbase databases sleep when idle and wake when you connect, so a quiet database costs nothing to keep around. This is what each state means, what brings a database back, and how to restore or permanently delete one. The short version: your data is safe at every step, and connecting is usually all it takes to resume.

The states

There is one more state that is not part of the idle-sleep cycle: locked. Downgrading to a smaller plan freezes any databases over the new plan's limits (or on engines it no longer includes) instead of deleting them, and only after a 72-hour warning window: we email you the list and the deadline first, and your databases keep running until it runs out. A locked database keeps its data but blocks connections until you free up room or upgrade. See Locked databases for the recovery paths.

Hibernation (auto-sleep)

Idle databases hibernate automatically. Hibernation is cheap and reversible: the database keeps its hostname, port, and volume, so the first new connection wakes it in roughly one to five seconds for most engines and the query then runs normally. You do not need to do anything - just connect.

This includes MySQL and MariaDB: a hibernated database wakes on the first connection to its port. The one state that does not wake on connect is a database you explicitly stopped - start it from the dashboard or CLI when you want it back.

Because hibernation happens on its own schedule rather than in response to anything you clicked, it can land while you have the dashboard open. A dashboard left open picks the change up by itself: it re-checks every 30 seconds while you are looking at it, and again the moment you switch back to the tab. You do not need to reload the page to see the current state.

Free databases must sleep

On the Free plan, that sleep is what makes the plan free, so it is also a requirement: a Free database is expected to be asleep for at least 25% of any rolling 7-day window, which works out to about 6 hours a day averaged over the week. Building on a database clears that by a wide margin. What does not is something holding it awake around the clock: a poller or cron job, an uptime or health-check monitor, a keep-alive ping, or an app serving traffic day and night.

If a Free database stays awake past the requirement we email you and give you a grace period to turn the poller off or upgrade. After that the database is put to sleep and paused there until the account upgrades: starting it and waking it by connecting are both refused, though nothing is deleted and your backups stay downloadable. You can also Export a paused database straight from its page without upgrading. The engine is started briefly to make the dump and the database stays paused afterwards, so an export can take several minutes, and it is limited to 5 exports every 24 hours. Upgrading lifts the pause right away, and turning on Settings > Availability > Always on is what then keeps it running all the time. If we lift the pause for you without an upgrade, the database page says so and tells you how long the pause stays off, and you press Start yourself when you are ready. Paid plans have no sleep requirement at all - always-on is exactly what they sell. See the acceptable use policy for the full rule.

Always-on (skip hibernation)

Need a database to never sleep? Turn on Always on under the database's Settings tab. Always-on draws from your plan's pool, so it is available on paid plans (Free has no pool). Use it for anything latency-sensitive where even a one-second cold start is too much.

An always-on database is pinned out of the whole sleep pipeline: it never hibernates, never auto-archives, and never reaches the day-90 removal. See Always-on databases for the pool math and how it is billed.

Platform updates

Your databases run inside a container that we keep patched: security fixes, engine fixes, and support for newer engine versions all arrive this way. We normally apply an update automatically while your databases are idle, so nothing interrupts you and you never hear about it.

A database that stays connected around the clock never gets that quiet moment. Rather than restart it underneath you, we leave it for you to choose: open the database and use the Update available card when you have a calm window. We may email you to point it out, and there is no deadline attached to it.

Applying it recreates the container, so every database inside it restarts together and open connections are closed. The restart takes between about 10 seconds and 2 minutes, depending on which engines you use. A client that reconnects on its own picks up within a few seconds, and one that does not will need a restart of its own, so it is worth doing when you are watching. Expect a handful of failed or slow queries during the window. Your data, connection strings, and settings do not change.

Nothing stops working if you wait, but staying current is how your databases receive the latest patches, and an update can be needed before you create a database on a newer engine version.

Stopping a database

Use Stop on the database's page to take it offline on purpose. Unlike hibernation, a stopped database will not wake on connect - you start it back up manually when you are ready. Stopping is a clean pause; nothing is deleted.

Shutting down is not always instant. While it runs, the database shows stopping and the Stop button is grayed out; the dashboard updates itself the moment it lands on stopped. Most databases stop in a second or two, but one under heavy load can take a minute or two to close its files cleanly. You do not need to press Stop again - the shutdown carries on in the background even if you close the page.

Archiving and restoring (Free tier)

A Free database that stays idle for about two weeks is archived. Archiving removes its live network address to reclaim shared capacity, so connecting returns an error that points you to restore it. Your data and backups are retained - this is not a deletion.

To bring it back, open the database and click Restore. Restoring rebuilds its address and starts it again, typically in ten to thirty seconds, and the database returns to running. Paid plans never auto-archive, so this only applies to Free.

You can also Export an archived database straight from its page, on any plan. The export briefly starts the engine behind the scenes, hands you a full dump, and leaves the database archived, so the removal countdown below is unchanged. This matters if your plan no longer includes the database's engine (for example a Free account with a MySQL database): Restore then asks you to upgrade first, but the export is never gated.

Long-archived free databases (90 days)

If a Free database stays archived for about 90 days, it is removed to free up shared capacity. We email you before this happens. Removal reclaims the live resources, but we always keep your most-recent backup - we never delete your last copy. To avoid removal entirely, restore the database (which resets the clock) or upgrade to a paid plan, which is never archived or removed.

A removed database is not a dead end. It shows as Removed and cannot wake on connect, but you can one-click Restore it: the database is re-provisioned from the kept backup with the same connection details, or you can download that backup instead. Only an explicit Restore brings it back - a database in this state stays parked until you act.

Deleting a database (Destroy)

Permanent deletion lives under the database's Settings tab, in the Danger Zone, as Destroy database. Only the owner sees it. Because it cannot be undone, you confirm by typing the database name first.

Destroy permanently removes the database, its data, and its connection history, and any connected clients lose their connection immediately. Before anything is torn down, Layerbase secures a recoverable backup - the platform is built to never silently lose your data, so if that final backup cannot be captured, the delete is refused rather than risking the only copy.