SnapbackSecurity
Snapback reads your database. That deserves a straight answer about what we can and cannot do with it. Here it is.
Least privilege
Onboarding gives you SQL to create a dedicated read-only role. We never ask for your service_role key. Revoke it with the two lines below and we lose access immediately.
No write credentials stored
Restores will work by generating SQL for you to review and run. There will be no write credential in our database to steal. One-click restore, when it ships, will hold that credential in memory only.
Encryption
Connection credentials will be sealed with KMS envelope encryption. Backups will be AES-256 encrypted at rest. All transport will be TLS-only.
Network lockdown
We will publish our fixed egress IPs at launch. Add them to Supabase Network Restrictions and your database refuses connections from everywhere else — including from us, if you change your mind.
Your data, your control
One click will delete every backup and every credential we hold. Bring-your-own storage — backups written straight to your own S3 or R2 — is on the roadmap.
Transparency over certification
We're too early for SOC 2, and we'd rather not pretend otherwise. Instead we publish how the system actually works. Certification comes when the company is big enough to mean something by it.
create role snapback_readonly login password '...generated...';
grant usage on schema public to snapback_readonly;
grant select on all tables in schema public to snapback_readonly;
alter default privileges in schema public grant select on tables to snapback_readonly;The exact SQL we hand you at onboarding. Nothing here grants write access.
drop owned by snapback_readonly;
drop role snapback_readonly;Revoking is two lines. Run them and we lose access immediately — no support ticket, no waiting on us. Note that drop owned by only covers the database you run it in, so run it in every database the role can reach before dropping the role.