Data handling

Where we store data, how long we retain it, and who can access it. For privacy rights and policies, see Data privacy & policy.

Last updated: March 2025

Data we process

  • Account data: Email, name, profile role, workspace memberships. Used for authentication, authorization, and product experience.
  • Content data: Projects, reports, report versions, experiments, pipelines, datasets (e.g. uploaded CSV metadata and processed data). Used for analytics, report generation, and pipelines.
  • Usage and audit data: Action type, resource type/id, timestamps, optional metadata; activity logs include IP and user-agent where provided. Used for billing, product analytics, and audit trails.

Where data is stored

Application and database: Stored in the application database (PostgreSQL) provided by Supabase. This includes profiles, projects, reports, report_versions, experiments, pipelines, datasets, workspaces, workspace_members, subscriptions, usage_logs, activity_logs, and related tables. Data residency depends on the Supabase project region (configurable in Supabase).

Authentication: User identities and sessions are managed by Supabase Auth (same Supabase project).

Payments: Stripe is used for subscription and billing. Customer IDs and subscription state are stored in our database; payment details and card data are held by Stripe, not in our database.

Errors (optional): If Sentry is configured (NEXT_PUBLIC_SENTRY_DSN), error reports and context may be sent to Sentry. See Subprocessors.

Retention

Retention is configured in the database (retention_policies table) and applied by separate jobs (e.g. pg_cron or external script). Default configured values:

Data typeDefault retain_daysNotes
usage_logs90Applied by retention job; export available before purge
activity_logs365Applied by retention job; export via audit API
Account, profile, content (projects, reports, etc.)While account is active; soft-deleted on account deletion (GDPR). Purge of soft-deleted rows can be implemented separately.

Who can access

  • End users: Via the application and API, subject to RLS. Users see only their own data and data in workspaces they belong to, according to their role.
  • Application backend: Uses Supabase with anon key (RLS applies) for user-scoped operations, and service role only for operations that require it (e.g. GDPR delete, audit export with compliance key).
  • Audit export: Authorized parties with the compliance API key can export activity and usage logs for a date range (see Audit log export).

Subprocessors

For a list of third-party providers used by the application, see Subprocessor disclosure.

Related