How does Spanner implement point-in-time recovery internally?

Point-in-time recovery (PITR) relies on Spanner's version_retention_period, a per-database setting (up to 7 days) that controls how long old row versions are kept before garbage collection instead of being purged immediately after being superseded.

ALTER DATABASE orders_db
SET OPTIONS (version_retention_period = '7d');

Internally, every write in Spanner is already timestamped by TrueTime and stored as a new version rather than an in-place overwrite, since Spanner is a multi-version system that needs historical versions anyway to serve stale reads. Extending the retention window simply keeps those historical versions around longer. A stale read or read-only transaction can then specify an exact past timestamp within that window, and Spanner reconstructs the database (or a specific table) as it existed at that instant by reading the appropriate row versions from each split, effectively giving a consistent snapshot without restoring from a separate backup file. This is why PITR in Spanner is fast to initiate compared to restoring a traditional backup - it reuses existing multi-version storage rather than replaying a backup image - but it is bounded by the retention window, so anything older requires a full backup restore instead.