Snapback

Security

Snapback reads your database. That deserves a straight answer about what we can and cannot do with it. Here it is.

  1. Least privilege

    Onboarding gives you SQL to create a dedicated read-only role. We recommend Supabase's pooler connection format first. We never ask for your service_role key. Revoke the role with the SQL below and we lose read access immediately.

  2. Read-only in beta/free

    Beta and free accounts do not register write-capable credentials. Snapback can read snapshots and diffs, but it cannot write back to your database.

  3. Encryption

    Connection strings are encrypted with AES-256-GCM before storage. The beta key lives in our environment; KMS envelope encryption comes after the beta. All transport is TLS-only.

  4. Network lockdown

    The beta does not have fixed outbound IPs yet. If your database only accepts an IP allow-list, Snapback may not be able to reach it until fixed egress is available.

  5. Your data, your control

    One click will delete every snapshot and credential we hold. Bring-your-own storage — backups written straight to your own S3 or R2 — is on the roadmap.

  6. 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.

  7. Visitor analytics

    This marketing site uses Google Analytics to count visits and beta sign-ups. It records page views and a sign-up event with no personal details attached, and GA4 anonymizes visitor IP addresses on collection. The Snapback app itself carries no analytics. We don't sell this data, and we don't share it with anyone beyond Google Analytics itself.

create role snapback_ro with login password '...generated...';
grant connect on database your_database_name to snapback_ro;
grant usage on schema public to snapback_ro;
grant select on all tables in schema public to snapback_ro;
alter default privileges in schema public grant select on tables to snapback_ro;

The exact SQL we hand you at onboarding. Nothing here grants write access.

drop owned by snapback_ro;
drop role snapback_ro;

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.

Want to see what changed in your Supabase database?

Join the beta