Guide
Point-in-time restore
Point-in-time restore (PITR) recovers a PostgreSQL database to an arbitrary moment, not just to the last backup. Layerbase archives the database's write-ahead log (WAL) continuously, so a bad migration or an accidental DELETE costs you seconds of history instead of everything since the last scheduled dump. It is rolling out starting with Layerbase's own production database, for the always-on PostgreSQL class.
What it covers
PITR applies to always-on PostgreSQL databases. Postgres is the only engine with WAL-based replay today; other engines keep their regular backup schedule. Always-on matters because archiving pauses while a database sleeps: a database that never sleeps has a continuous history. Layerbase runs its own production Payload database on this exact pipeline, which is also how the feature gets drilled for real.
Turning it on
Point-in-time restore is a switch on your database's Backups tab, and it is off until you turn it on. The switch appears on databases whose engine can do it (PostgreSQL) and is available on paid plans for a database that is pinned always-on, since archiving pauses while a database sleeps. If your database is on a free plan or is not pinned always-on, the switch is still there, grayed out, and says which of the two to change. As the feature rolls out, the switch reaches accounts in stages, so a database that qualifies may not show it yet.
Once it is on, the Backups tab shows how fresh the archive is and how far back the window reaches, and a Restore to a moment action opens a timestamp picker bounded by that window. Pick a moment, optionally name the result, and Layerbase builds a new database at that point in time. The restored copy is an ordinary database: it counts toward your plan and bills like one, so delete it when you are done with it.
How a restore behaves
A point-in-time restore produces a new database. Layerbase takes the newest base snapshot from before your target time, replays the archived WAL onto it up to that moment, and brings the result up as a separate instance with its own connection details. The original database is never touched, so a restore is always safe to try: you can inspect the restored copy, pull what you need out of it, or switch your application over to it, without risking the live database.
The timestamp semantics are exact. A transaction that committed before your target time is present in the restored copy; a transaction that committed after it is absent. If you know the bad write happened at 14:32:10, restoring to 14:32:00 gives you the world as it stood ten seconds before the mistake.
How it relates to backups
PITR does not replace regular backups; it fills the gap between them. Scheduled dumps keep running on their own cadence and remain a second, independent recovery path: a plain, portable dump you can download, inspect, and restore anywhere, with no dependency on the WAL archive. WAL archiving adds the replay in between, so recovery points are no longer limited to the dump schedule. Every restore, from a dump or from the archive, is checksum-verified before anything runs.
Design choices worth knowing
The archiver that runs beside your database is a plain file copy with no credentials in it: object-storage credentials never enter the database container. Shipping to storage happens on the host, continuously, and a stalled shipper can never fill the server's disk - the archive spool is bounded, and if it ever hits its ceiling the system sheds archiving load loudly (with operator alerts) rather than letting the database itself run out of space. A broken archive chain is recoverable with a fresh base snapshot; a full disk is not.
Common questions
Does a restore affect my live database? No. The restore builds a new instance from the archive. The source database keeps running, untouched, throughout.
Which engines have PITR? PostgreSQL only today. WAL-based replay is a Postgres mechanism; other engines continue to rely on scheduled and manual backups.
How far back can I restore? The archive keeps a rolling window measured in days, anchored by daily base snapshots. Within that window, any timestamp is reachable.
How fresh is the archive? WAL segments ship continuously as they fill, and an idle database forces a segment out at least once a minute, so the archive stays within seconds to about a minute of the live database.