How does the VEC GDPR cleanup job actually work?

The cleanup that enforces our 15-day retention is not a manual step — it is a scheduled job that runs every day on the Valid Email Checker backend. The job is a Supabase edge function that calls a stored procedure to drop database rows past the retention cutoff, then walks the storage bucket to remove the matching source files. Every run writes a row to a gdpr_cleanup_logs table so we can audit when the job ran, what it removed, and how long it took.

Step 1: database cleanup via stored procedure

The function first calls a Postgres function named perform_gdpr_cleanup_all. That procedure reads the active data_retention_days from system settings (default 15), computes the cutoff date, and deletes verification result rows older than that in batches. Batching matters because some accounts have millions of result rows from a single bulk job; trying to drop them in one transaction would lock the table for too long. The procedure returns counts: tasks_cleaned, results_deleted, and the retention_days it used, which the edge function logs and then carries into step two.

Step 2: storage cleanup in batches

After the database is clean, the edge function pages through completed verification_tasks whose results_deleted_at is set (meaning the rows were just dropped) and constructs the storage paths for their source files. It deletes 100 files per Supabase storage API call, with a small delay between batches to stay under rate limits. Two kinds of files get removed: the original uploaded list at bulk-tasks/<vec_task_id>.txt, and any failed_emails_storage_path artifact attached to the task. Both are gone for good after this step.

Step 3: audit log update

The function then updates the latest gdpr_cleanup_logs row with the final file count, the execution time in milliseconds, and any errors that surfaced during storage deletion. If storage errored on a batch (a temporary 5xx, for example), the error string is kept in the audit log so the next run or a support investigation can see what was retried. Our SRE team alerts on failed runs.

What this means for you in practice

• You do not need to delete anything to comply with the 15-day retention — VEC does it for you on every account, every day.
• The window is hard-enforced at the database level, not just hidden in the UI. Even a customer-support engineer cannot pull a list back after cleanup.
• The audit log is internal but our compliance team uses it to demonstrate retention enforcement during SOC2 and GDPR reviews.
• If you need a shorter window for compliance reasons, the retention value is configurable on enterprise contracts.