Point-in-time recovery comes from each engine's native tool (pgBackRest, binlog, TiDB log backup), orchestrated but not reimplemented. The platform standardises the promise and the recovery-point map, not the replay code.
Every adapter implements the same contract: capture, write the envelope, report size, duration, log position, checksum and consistency level. A missing or unreadable result is a failed capture.
Volume snapshots are marked crash-consistent unless the owner declares a freeze hook. Restoring one of a running database is a crash recovery, and the catalogue says so.
Numbers
Tier 1 PostgreSQL: weekly full, daily differential, hourly block-incremental. Maximum chain depth 25, and never more than 7 days from a full.
WAL archive timeout is 60 s, which is what actually sets the 5-minute RPO. The rest is margin for the async push queue.
Risks
Tool-native expiry (pgBackRest expire, Velero repository maintenance, TiDB log truncate) wants to delete. It is switched off for capture identities and run by the disposal identity, with Object Lock as the backstop if its retention setting is ever wrong.
ClickHouse backup to an encrypted disk over S3, and TiDB BR against a locked bucket, are the two adapter behaviours the proof of concept must confirm before they are relied on.
