How backup verification works

Uploading a dump proves that a file exists. ReviveDB verifies a recovery point by restoring it and comparing the result with an inventory captured from the same Supabase Postgres snapshot.

One consistent source snapshot

One exported snapshot of your Supabase Postgres database feeds both the logical dump and the source inventory. That prevents normal application writes from creating false mismatches between what was dumped and what was counted.

Isolated database restore

The dump is restored into a short-lived, isolated Postgres verification database using the matching supported client. ReviveDB rejects Supabase projects on an unsupported Postgres version before saving a connection.

Structural and data comparison

• Required schemas, tables, columns, indexes, constraints, functions and triggers.
• Table row counts and sequence state.
• Required Postgres extensions and their availability in the verification environment.
• Supabase Storage object size and SHA-256 for every captured file.

A verifiable mismatch fails the run. Failed replacement runs do not remove the last verified recovery point on the Free plan.

What verified does not claim

• That secret values or external service credentials were copied. Those values remain manual.
• That every possible future target environment will accept the recovery point without preparation.
• That amber or unavailable components became complete because the database passed.