Data handling

SQLAnvil Cloud is a control plane: it orchestrates runs and shows you results. This page is the plain statement of what that means for your data — what we store, where, for how long, and the one thing you should keep out of your SQL.

What we store

When a run executes, we record, per action (table/view/assertion/operation/export/import):

• Metadata — the target (schema.name), type, status, start/duration, the source file, and the identity the run connected as. Low-sensitivity; kept as run history.
• Run detail — the compiled SQL for the action and, on failure, the verbatim warehouse error. This is what powers the run-detail view and “Copy failure context”.

We also keep the run’s overall status, branch/PR/commit, and a tail of the run log.

Where it lives, and who can read it

• Stored in our control-plane database (Supabase Postgres), encrypted at rest.
• Protected by row-level security: a run and its detail are readable only by the project’s owner. Other customers cannot see your runs.
• Run detail is stored in plaintext (not end-to-end encrypted). Operationally this means SQLAnvil could read it; we use it only to run and display your runs, never for anything else, and there is no support team browsing your data (SQLAnvil Cloud is fully self-service).

Retention

The sensitive fields — the compiled SQL and the error text — are scrubbed 30 days after a run finishes. The lightweight metadata row (target, status, timing) is kept so your run history stays intact. Deleting a project removes its runs.

What we never store

• Warehouse credentials. They are brokered at run time, never custodied — see Warehouse connections.
• Your table data. We don’t copy rows out of your warehouse. We store the SQL text and error text of a run — not query results. (But note the next section: SQL and errors can contain data.)

Important: don’t put secrets or sensitive data in your SQL

Because run detail is stored in plaintext, treat your compiled SQL and warehouse errors as visible to the platform. Two ways data can leak into them:

• Inlined literals — select 'my-secret-token' as t or a hard-coded PII value lands verbatim in the stored compiled SQL.
• Error echoes — a warehouse error can quote a row value (e.g. a unique-constraint violation printing an email address) into the stored error text.

This is standard hygiene for any CI system (build logs are not a vault). The rule:

• Never inline secrets or sensitive values in models. Reference secrets through your warehouse’s own mechanism, not SQL literals.
• Keep PII out of hard-coded values, seed VALUES (...), and assertion messages.

If you have a hard requirement that the platform be unable to read run detail at all, that’s a client-side-encryption model we can discuss — but plaintext + RLS + 30-day scrub is the default.