Point-in-time restore is generally available, including FerretDB

Point-in-time restore is on. If you run an always-on PostgreSQL or FerretDB database on the Pro plan, there is now a switch on its Backups tab that starts archiving the write-ahead log continuously, and a restore control that takes a timestamp and hands you a new database containing your data as of that moment. The worst-case recovery point drops from about an hour, which is how far apart scheduled dumps sit, to seconds under write load, bounded by about a minute when the database is idle. Your scheduled dumps keep running underneath, unchanged.

We shipped the mechanism first and ran it on our own production database before offering it to anyone. That story, including the failed first attempt and the disk-safety design, is in the build post. This post is the shorter, more useful one: what the feature does now that you can turn it on.

Where the switch is

Open a database, go to the Backups tab, and turn on point-in-time restore. The database has to be always-on and on the Pro plan; more on why below.

Turning it on does three things: it restarts the engine with archiving enabled, takes an initial base backup, and starts shipping WAL segments to object storage as they close. On the layerbase.com production database, the whole sequence took 21.1 seconds, and the base backup inside it was 5.26MB compressed. After that the archive is continuous and there is nothing to schedule, tend, or remember.

What a restore actually produces

A restore produces a new database. Not a rollback, not an overwrite, not a maintenance window on the database you are worried about.

You give it a timestamp. We take the newest base backup from before that timestamp, verify its checksum, replay the archived WAL segments onto it up to your target, and bring the result up as a separate instance with its own connection string. The source database is not written to at any point in the operation. When the restore finishes you have both copies, and you decide what happens next: compare them, copy a table across, repoint your application, or throw the restored one away.

The boundary is exact, and it is worth stating in the plainest terms available: a transaction committed before your target is present in the restored copy, and a transaction committed after it is absent. Not approximately, not to the nearest snapshot.

The receipts, from the supervised drill on our own production Postgres:

targetTime          2026-08-26T15:19:30.000Z
restore duration    32.3s (API call to promoted, connectable database)
segments replayed   6
tables              46        (matches production)
user rows           823       (sane against the live count)
migrations          123
rows after target   0         (across every table)
newest replayed row rate_limit_event at 15:19:13.781 UTC

That last row is the feature in one line. It was written by live production traffic two minutes after the base backup was taken and sixteen seconds before the restore target, so the only path by which it could exist in the restored copy is WAL replay. Everything before the target is there. Nothing after it is.

The dumps did not go anywhere

Scheduled logical dumps keep their schedule and their retention. Nothing about your existing backup behavior changed, and that is deliberate rather than incidental.

A dump is a second recovery path with no dependency on the WAL archive, and it is portable in a way a physical archive is not. Point-in-time restore is precise but chained: it needs a base backup plus every segment after it. If that chain ever breaks, and ours will deliberately break rather than let a stalled shipper fill a shared disk, the dumps are untouched and the system re-anchors itself with a fresh base backup once shipping drains. Two independent mechanisms with different failure modes is the whole design. One of them being better is not a reason to delete the other.

FerretDB gets point-in-time restore, and that is the interesting part

FerretDB is a document database. It speaks the MongoDB wire protocol, your mongodb:// connection string and your driver do not change, and until now the mental model most people carry is that document databases get snapshots while relational databases get replay.

FerretDB on Layerbase stores its documents in PostgreSQL. That is not an implementation footnote here, it is the entire reason this works: documents written through the Mongo wire become rows, rows are written through the write-ahead log, and the write-ahead log is the thing we archive. So a FerretDB database inherits Postgres's replay machinery without anyone writing a document-database equivalent of it. You get restore-to-any-timestamp on a database you talk to with insertOne and find.

We drilled it on staging against FerretDB 2.7 before turning it on, because "it should follow" is not a durability claim:

enable              26.9s (including a 4.32MB base backup)
restore             49.9s, 5 segments replayed
verification        over the MongoDB wire, not against Postgres

The verification is the part that mattered. We wrote one document before the target and one after it, then connected to both databases with a Mongo client. The source returned both documents. The restored copy returned exactly the pre-target one. Same driver, same query, two answers, and the difference between them is the timestamp we asked for.

One detail that surprised us pleasantly: the restored copy accepted the source database's own Mongo credentials. FerretDB's SCRAM authentication state lives in Postgres too, so it travels inside the physical base backup. There is no separate credential dance to do after a restore. You point the same connection string at the new host and you are in.

Scope, stated honestly

Three limits, all real, none of them marketing hedges.

Always-on databases only. Archiving pauses while a database sleeps, and a continuous history needs a continuously running database. A database that hibernates has gaps in its WAL stream by definition, and a gapped chain cannot honestly promise restore-to-any-timestamp. That is a physics constraint of the mechanism, not a packaging decision. Which plan it comes with is a packaging decision, and we will name it rather than blur it: point-in-time restore is included on the Pro plan and up, on databases you have pinned always-on.

PostgreSQL and FerretDB only. WAL replay is a Postgres mechanism. FerretDB is included because it is Postgres underneath. Every other engine in the catalog keeps its scheduled and manual backups, and we are not going to imply otherwise on a comparison table. If your engine is not on that list, nothing about your backups changed today, in either direction.

A restore leaves you with two databases. That is the safe-by-default design working as intended, not an oversight, but it is worth knowing before you reach for the button mid-incident: the restored copy is a real database that sticks around until you do something with it or delete it.

FAQ

How precise is the target?

Exact at transaction granularity: committed before your target means present, committed after means absent. The limit is not the precision of the target, it is how recent a target you can pick. Under write load that is seconds behind now; when a database is idle it is bounded by about a minute, because a WAL segment still has to close before it can ship.

Does restoring touch my live database?

No, and this is the design decision we would defend hardest. The restore builds a separate instance with its own connection string and never writes to the source. That makes it something you can reach for early, while you are still working out what happened, rather than a decision you have to be certain about first.

Does this replace my scheduled backups?

No. Dumps keep their schedule and retention and remain a fully independent recovery path. Point-in-time restore sits between them.

Which engines have it?

Always-on PostgreSQL and always-on FerretDB, on the Pro plan and up. Everything else keeps scheduled and manual backups.

Why does a sleeping database not get it?

Because archiving stops while the database is stopped, so the WAL history has holes in it. We would rather say "not on this class of database" than ship a restore-to-any-timestamp button that quietly means "any timestamp your database happened to be awake for".

Is FerretDB's version a different, weaker thing?

Same mechanism, same guarantees. The documents are rows in Postgres, so the archive and the replay are the ones described above. The only FerretDB-specific behavior we found is a convenience: authentication state travels with the base backup, so the restored copy takes the same Mongo credentials.

Turning it on

It is a switch on the Backups tab of an always-on PostgreSQL or FerretDB database. The point-in-time restore doc covers the operational details, the backups doc covers how it sits alongside dumps, and the build post is the engineering receipt for how the archiver stays out of your container and off the host's disk.

If you do not have a database here yet, start one.