What Restorable is not

Restorable backs up databases, restores them in an isolated environment, runs your checks, and signs a receipt. That is the full job description. This page spells out the scope boundaries and the engines we support so you can decide quickly whether the product fits.

Databases only

A source in Restorable is a database the agent can reach with its engine's client tools. Postgres is stable; MongoDB is in beta. Other engines are not supported.

Engine compatibility

Engine	Status	Versions	Dump tool
Postgres	Stable	13 – 17	pg_dump / pg_restore
MongoDB	Beta	6, 7	mongodump / mongorestore

The managed providers we routinely see customers use with Restorable: Scaleway Managed Database, Hetzner Managed Postgres, OVHcloud Managed Postgres, Crunchy Bridge, Neon, Supabase, MongoDB Atlas (EU regions). Any endpoint reachable by the agent with valid credentials and the engine's dump tool works.

What we do not back up

Three categories are explicitly out of scope. If your goal is any of these, Restorable is not the tool.

Files and filesystems

We do not back up file trees, S3 buckets, object stores, NFS shares, or local disks. Use a file-level backup tool for that. Borg, restic, and duplicity are mature, open source, and cover the use case well.

SaaS application data

Restorable does not pull data out of Stripe, GitHub, Linear, Notion, Intercom, HubSpot, Salesforce, or any other SaaS API. That shape of product is a different architecture: we would need to be a data processor with access to the customer's plaintext, and the whole trust model of Restorable rests on us not being that.

If you need SaaS data protected, the established category is SaaS-backup tools like Rewind and HYCU. They are processors, and they are the right shape for that job.

Managed keys

There is no "we hold your keys for you" tier. Ever. The agent holds your keys because the product's central claim depends on us not being able to read your data. A tier where we hold keys would turn that claim into "we mostly do not read your data," which is a different product.

If you need key-recovery insurance, the right pattern is customer-side escrow with custodians of your choosing. Restorable never becomes a custodian. (A built-in Shamir-split workflow is on the roadmap; today, escrow is operationally yours to run.)

Things Restorable is often mistaken for

A backup tool

We take backups, but we are not in the business of being your primary backup solution. We are in the business of producing evidence that a backup restores. If your setup already writes dumps to S3 and you like it, keep doing that. Restorable runs alongside and validates the dumps on its own schedule.

A monitoring tool

The weekly evidence email is not Datadog for backups. It does not page you at 3 AM. It lands in an inbox, on a cadence, as evidence for an auditor or an incident post-mortem. Failures trigger an immediate email; not a push notification.

A compliance-in-a-box tool

A signed receipt is evidence an auditor can accept under SOC 2 CC6.7, ISO 27001 A.8.13, DORA, NIS2, and C5. It is not, by itself, an auditor. Your SOC 2 report still involves a human walking through your controls. Restorable produces one of the artifacts that walkthrough references.

When Restorable does not fit

A short checklist. If any of these is true, you will have a bad time with Restorable, and we would rather you know now.

• Your database is on a private network the agent cannot reach, and you cannot run the agent inside that network.
• Your backups are so large that running a daily pg_dump is not feasible, and you rely on physical / block-level snapshots exclusively.
• You cannot give the agent a role that can run pg_dump (or the equivalent for your engine).
• Your compliance regime requires the backup vendor to be a processor with access to plaintext. We are not that kind of vendor.

The first three have workarounds we can help with. The fourth is a structural mismatch; the right answer is a different product.