A snapshot preserves a database state that can support recovery or testing. The engineering question is whether you can restore the right state, validate it and safely reconnect the application. Creating a snapshot alone does not prove that recovery meets the business requirement.

Why study this now?

Databricks lists the Lakebase snapshots API as Beta on 15 September 2026, including restoration into a new branch. Releases are staged. The exercise below is a platform-neutral drill, not a tested Lakebase deployment recipe. Read the release notes.

A synthetic incident timeline

A database has a known-good snapshot at 10:00 UTC. A faulty update damages records at 10:12. The team detects it at 10:15 and makes a validated replacement available at 10:35. If the replacement contains only the 10:00 state, up to twelve minutes of legitimate pre-incident changes may be absent. Later valid activity also needs reconciliation.

The observed recovery time from incident to availability is 23 minutes. Recovery point objective (RPO) is the permitted data-loss window; recovery time objective (RTO) is the target time to restore service. Objectives are requirements agreed beforehand, while the measured intervals describe this drill.

Compare the result with the requirement

Suppose the required RPO is five minutes and the RTO is thirty minutes. This snapshot-only drill meets the time target but misses the data-loss target. A newer recovery point or supported replay strategy might close the gap. Check actual database capabilities and retention before promising either.

Validate the restored branch

1. Identity: record the source, snapshot time and restore destination. Check that the application is not still reading the damaged source.
2. Completeness: compare counts and business totals at the snapshot cutoff. A 10:00 restore should not be expected to equal a live 10:30 report.
3. Integrity: test unique order keys, required fields and relationships between orders and lines.
4. Application behaviour: test representative reads and, in an isolated environment, a write followed by a read. Verify credentials and permissions.
5. Reconciliation: identify valid changes after the snapshot and recover them without repeating the faulty update or external side effects.

Consider systems outside the database

Restoring an order does not automatically undo an email, payment or shipment. Track external identifiers and use supported idempotency controls for replay. Isolate a practice restore from production traffic so it cannot resend customer notifications.

Keep the timeline, validation queries, rejected records and cutover decision in a runbook. Record who authorises the switch and how to reverse it if the replacement fails. Measure a second drill after changing the procedure.

Interview question

“Our restore completed in eight minutes. Are we protected?” Ask which data was restored, how much was lost, whether the application passed validation and whether downstream effects were reconciled. Restore speed answers only part of the question.

Continue with safe pipeline retries and quality checks.

← All articles · Suggest a correction