Recovery & Delete Control is now in early access: use it on your own database nowuse it now

Resilient data infrastructure

Data that outlives its operators.

One layer in your own cloud that decides what may happen to your data, and proves what did. It starts with your production database: a verified copy in a separate account DataPrism cannot reach, restored on a regular schedule, and destructive changes that wait for it. We hold no key.

Request early access How it works

Production mistakes shouldn't be permanent.

Teams now let AI agents, scripts and CI change production. One wrong command is enough to lose a database, and the backups often go with it, because they live under the same account. On Supabase, deleting a project permanently removes its backups too.

In February 2026, a Terraform command run by an AI coding agent wiped the production infrastructure behind the DataTalks.Club course platform, automated snapshots included. The founder's post-mortem describes a recovery that took about 24 hours and a support upgrade.

Auditors and customers now ask for proof that you can restore.

$deletedatabaseprodrefusedgranted
A design, not part of the demonstration. Agents, scripts and CI keep the access they need to work. An organization policy denies the destructive actions to every identity except an executor installed in the cloud account, so the only path to destroying production runs through it. The executor is designed to grant a destruction only when a locked copy, restored successfully, covers the state being destroyed, and to write every grant and every refusal to a log that is checked without DataPrism.

One layer in your own cloud.

1

Keep a locked copy

Your Postgres database is copied continuously into a separate account DataPrism cannot reach, encrypted and locked for a set lock period.

2

Prove it restores

On a regular schedule, the copy is restored into a throwaway database, and a signed attestation records the result. Each attestation is evidence of a working restore, ready for your auditor, and is designed to show your recovery time before you need it.

3

Make destruction wait

Destructive changes, such as deleting a database, its backups or its keys, are designed to wait until a verified copy covers them. Agents, scripts and CI keep the rest of their access.

You install it with your own credentials; during early access, we do it together. See how it works in detail

The difference you can check.

Each of these comes from how DataPrism is built, not from a contract.

  • We hold no key.

    The copy is encrypted with a key from your KMS. DataPrism never holds it, so we cannot read the copy.

  • We have no role in your accounts.

    The copy sits in a separate account. We cannot delete it or shorten its lock period.

  • We cannot change what runs there.

    You pick the release that runs, and we cannot swap it for another one.

Your cloud provider is a different matter: with the default setup, it holds the copy, the key and the compute. The security page lists every limit.

Every operator can fail. Your data should not go with it.

That includes us. We start with your production database and build the rest on the same base.

Read the vision

Early access is open.

For software teams where AI agents, scripts or CI can change the production database, and where an auditor or a customer asks for proof that you can restore. Pricing on request.

Request early access