Right-to-erasure removes or anonymizes all PII within documented window

GDPR Art. 17 and CCPA §1798.105 grant users the right to erasure — setting an is_deleted flag satisfies neither. Name, email, profile picture, and bio left in the database after a deletion request remain queryable by anyone with direct database access, exploitable via SQL injection (CWE-212), and constitute a reportable breach under GDPR Art. 83. Regulators have levied fines for exactly this pattern: data nominally 'deleted' but fully intact in the store.

Implement erasure at the database layer — either cascade-delete PII columns or replace them with an anonymized placeholder on the user row. Update all derived tables (social graph, activity logs) in the same transaction to prevent orphaned references. Example anonymization trigger:

CREATE FUNCTION anonymize_user_on_delete() RETURNS TRIGGER AS $$
BEGIN
  UPDATE users SET
    email = NULL,
    phone = NULL,
    profile_picture_url = NULL,
    bio = NULL,
    first_name = 'Deleted',
    last_name = 'User ' || OLD.id,
    deleted_at = NOW()
  WHERE id = OLD.id;
  RETURN OLD;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER user_deletion_trigger
BEFORE DELETE ON users
FOR EACH ROW EXECUTE FUNCTION anonymize_user_on_delete();

Document the deletion window (e.g., immediate vs. 30-day grace) in your privacy policy to satisfy the "documented window" requirement.