I built Revenant to prove PostgreSQL backups actually restore — in CI, on AWS, without touching your app code.

A team I know had green backup alerts for six months straight.

Every day, the backups completed.

Snapshots were being created on schedule. Retention was configured. Monitoring was quiet.

As far as everyone could tell, the database was protected.

Then one day, they needed to restore it.

The snapshot restored successfully.

The database started.

And then the application broke.

A migration that should have been there had never been applied to the restored instance. A critical table was empty. The first real query hit a foreign key constraint and failed.

Nothing was wrong with the backup.

The problem was that nobody had ever proved the restore actually worked.

That distinction sounds obvious, but it's surprisingly easy to miss.

Most teams have automated checks around whether a backup job completed. They know a snapshot exists. They know how long it's retained. They know the storage is healthy.

But a successful backup only tells you that you copied some bits somewhere.

It doesn't tell you whether those bits can become a working database again.

And that's the gap I wanted to solve.

So I built Revenant.

Revenant is an open-source CLI that validates PostgreSQL restores.

The idea is deliberately simple.

You tell Revenant what a healthy database looks like in a revenant.yaml file.

Maybe your customers and orders tables need to exist.

Maybe orders should never be empty.

Maybe the foreign key between orders and customers must remain intact.

Maybe there is a query that should always return data.

Maybe the newest order shouldn't be more than 24 hours old.

Those rules are specific to your business, so Revenant doesn't try to guess them.

You define them once.

Then Revenant runs them every time you validate a database.

For example:

plan: my-app-validation

database:
  engine: postgres
  connection: ${DATABASE_URL}

checks:
  - type: connect

  - type: schema
    expect_tables:
      - customers
      - orders

  - type: row_count
    table: orders
    min: 1

  - type: foreign_key
    table: orders
    references: customers

  - type: golden_query
    query: "SELECT count(*) FROM orders WHERE status = 'paid'"
    expect_min: 1

  - type: freshness
    table: orders
    column: created_at
    max_age: 24h

Then:

revenant verify

The result isn't just "command succeeded."

You get evidence:

✓ customers table exists
✓ orders row count 42 >= 1
✓ foreign key orders -> customers intact

Restore Validation: PASS

Wrote report.json
Wrote report.md

That report is useful because it answers a much more important question than "did the backup job run?"

It answers:

Can we actually use this database?

And because Revenant only talks to PostgreSQL, it doesn't care what your application is written in.

Node. Python. Go. Rails. Java.

It doesn't need to read your source code or understand your application architecture.

You can run it locally, in CI, or on a schedule.

We also built a GitHub Action so teams don't need to install Go or manage another runtime just to run the checks.

Set your DATABASE_URL, add the workflow, and let the pipeline periodically prove that your database still passes its restore validation rules.

The more interesting part is what happens with AWS RDS.

For RDS, you can take the validation one step further.

Revenant can find an RDS snapshot, restore it into a temporary sandbox, run your validation plan against the restored database, collect the results, and tear the sandbox down.

In other words, you're not just checking whether a database looks healthy today.

You're testing the thing you actually care about:

Can we recover from the backup we would use during an incident?

The current release includes the CLI, GitHub Action, PostgreSQL validation checks, JSON and Markdown reports, and the AWS RDS restore workflow.

It's free, open source, and Apache-2.0 licensed.

We've also started thinking about what comes next.

A single revenant.yaml works well when you're validating one application.

But organizations eventually have dozens or hundreds of databases.

That's where we're heading with the hosted layer: fleet-wide restore drills, scheduling, signed evidence, and a central place to see whether your databases can actually be recovered.

But the core idea won't change.

I've seen too many disaster recovery plans boil down to:

"We have backups."

I think the better statement is:

"We have backups, and we prove that they restore."

Because the worst time to discover that your backup doesn't actually recover your business is when you're already in the middle of an incident.

That's why I built Revenant.

If this problem sounds familiar, give it a try.

CLI: https://github.com/277pawan/revenant-cli

GitHub Action: https://github.com/277pawan/revenant-action

And if you find something that breaks, open an issue.

We're building this with early users, and those real-world restore failures are exactly what we want to learn from.

**Don't just back up your database.

Prove you can recover it.**