All pages

What we operate

Everything below is what you would find out anyway. The question is only whether you find it out now or at three in the morning.

The short version

We operate the platform. You operate your database. A database here is a machine running the stock image, with a volume and a snapshot schedule. That is a genuinely good place to run one, and it is not the same thing as a managed database: nobody here is paged when your Postgres runs out of connections, and nobody here notices before you do.

What a managed database gives you	Here
The right configuration, made for you	Yes. `pilot add` writes it.
A volume that survives the host	Yes. Every write is in object storage.
Automatic backups, with retention	Yes. Daily by default, with dailies and weeklies kept.
Point-in-time recovery	Yes, for Postgres: a base backup plus the archived write-ahead log.
Restore to a new database rather than over the old one	Yes. A snapshot forks into a separate volume.
Somebody on call for it	No. That is you.
Version upgrades applied for you	No. You change the image tag and deploy.
Failover to a replica within seconds	No. See the recovery times below.
Tuning, index advice, query review	No.

The first five are most of the practical value, and they are the ones a platform can honestly deliver. The last four are a company rather than a feature.

How much data you can lose, exactly

This is the number nobody publishes. In the default Postgres mode, up to a minute. The data directory is on the machine's local disk and write-ahead log segments ship to the volume when they fill or when the timeout expires. If the host dies, everything committed since the last shipped segment is gone: not corrupted, gone, and not recoverable from anywhere, because it only ever existed on that host's disk. In exchange, a commit is a local disk write and does not wait for object storage.

In the durable-volume mode, and for every other engine, zero. The data directory is on the volume and a volume write is in object storage before it is acknowledged. In exchange, every commit waits for an object-storage round trip, which for a write-heavy workload is the difference between a fast database and a slow one. That is exactly why it is not the default, and why the command prints which one you chose every time.

How long recovery takes

Every other machine here comes back in well under a second, restored from a memory image with its processes already running. A database is the one place that headline does not apply.

What happened	What recovery is	How long
A host dies, default mode	The machine is rescued onto another host and cold-boots, because its memory image describes a filesystem the archived log has moved past. Postgres then replays the archive.	Seconds to minutes, proportional to what was written since the last base backup.
A host dies, durable-volume mode	The same rescue, then a volume mount, then the engine’s own crash recovery.	Seconds.
You restore a snapshot	The machine cold-boots deliberately: its memory image cached the filesystem you just replaced.	Seconds to a minute.
Point-in-time recovery	A base backup is unpacked and the log replayed to the moment you named.	Minutes, proportional to the distance from the base backup.

Every one of those is bounded and none of them is instant. If your application cannot tolerate minutes of database downtime, you need a replica, and you need to be the one who decides what failover means for your data.

What is and is not automatic

Automatic	Not automatic
Snapshots, daily by default, with retention.	Nothing fails over. A single database machine is a single point of failure for whatever depends on it.
The volume, in object storage on every write.	Nothing upgrades itself. An image tag stays where you put it, which is deliberate and is still work you have to do.
A filesystem check before any guest is given a volume.	Nothing tunes itself. Buffers, connection limits and indexes are yours.
Rescue onto another host, with the same id, name and URL.	Nothing watches your query patterns. Reading the metrics is you.
The health gate, so a deploy that cannot reach the database does not become the running release.

High availability, and whose it is

Pilots operates the machines, the volumes, the snapshots, the process supervisor, and the placement of each node on a different host where the fleet has one.
Pilots does not operate the choice of leader, the replication tuning, the decision to fail back, or the three in the morning. Nothing in the platform reads or writes which node is primary, deliberately: a leader recorded in a replicated row would be stale exactly when it mattered.
It does not protect you from a bad migration or a wrong delete, which replicate faithfully to every node. That is what recovery is for, and it is a different tool for a different failure.

Platform limits

Limit	What it means for you
A memory snapshot never crosses the processor-vendor boundary	The fleet may mix vendors, but a suspended machine wakes on a host of the same vendor, and a machine whose pool has no live host cold-boots from its own disk instead (checkpoints and forks).
A diff chain is exactly 2 levels	A template plus one per-machine difference. A checkpoint of a checkpoint of a checkpoint is refused when the header is parsed rather than failing later.
One region	Every host is in one European region today. Nothing in the design pins the fleet there, and a machine answers from that region wherever the request comes from.

The CLI

Limit	What it means for you
Linux and macOS, on both common processor families	There is no Windows binary, because the CLI does not build for Windows. WSL is Linux, so the install commands work there unchanged, and on Windows itself the npm launcher says so.
A checksum is not a signature	The checksum proves the file you received is the file the release published. Someone able to replace a release could replace its checksum too. The npm package carries a provenance record tying it to the commit and the workflow run that built it.