---
"@context": https://schema.org
"@type": TechArticle
"@id": https://www.twilio.com/docs/segment/unify/profiles-sync/deletions#article
headline: Profiles Sync deletions
description: Learn how Profiles Sync deletions propagate Segment profile deletion requests to your connected data warehouse.
url: https://www.twilio.com/docs/segment/unify/profiles-sync/deletions
inLanguage: en
dateModified: 2026-11-05T15:41:47.000Z
author:
  "@type": Organization
  name: Twilio Developer Education Team
publisher:
  "@type": Organization
  name: Twilio
---

# Profiles Sync deletions

* FREE: x
* TEAM: x
* BUSINESS: ✓
* ADDON: ✓

Unify requires a Business tier account and is included with Engage.

See the [available plans](https://segment.com/pricing), or [contact Support](https://segment.com/help/contact/)

Profiles Sync deletions let you propagate profile deletion requests from Segment downstream to your connected data warehouse.

This ensures that when Segment permanently deletes a profile from its internal systems, all associated data in your Profiles Sync tables, including identifiers, traits, and events, is also deleted. By deleting data in your downstream tables, you can maintain compliance and data integrity.

> \[!NOTE]
>
> Profiles Sync deletions remove profiles from your tables rather than appending a `deleted_at` field to your existing profiles.

## How Profiles Sync deletions work

When Segment receives a deletion request (such as a [GDPR "Right to be Forgotten" request](/docs/segment/unify/unify-gdpr)), the process occurs in two high-level phases:

* **Identification and staging**: Profiles Sync securely captures the deletion signals and prepares the corresponding Segment IDs for processing. This step ensures that Segment doesn't retain any personally identifiable information (PII) about your user during the deletion process.
* **Execution**: On a scheduled basis, Profiles Sync runs batch deletion operations directly within your connected data warehouse to remove all traces of the deleted profiles from your managed tables. This includes materialized views (like `user_traits` and `user_identifiers`) and append-only raw tables (like event tables and ID graphs). To clear the value of an individual trait, use [null trait propagation](/docs/segment/unify/profiles-sync/tables/#null-trait-propagation).

> \[!NOTE]
>
> Segment runs the deletion job once per week in production environments. This weekly sync lets the deletion job handle both bulk requests and sporadic bursts of requests without impacting your warehouse's performance during standard incremental syncs.

### Profile reintroduction

If a previously deleted user returns to your site or app (for example, after a 90-day inactivity deletion), Segment creates a new profile for that user.

Segment takes the following steps:

1. Detect the returning user as a new entity.
2. Assign a new canonical Segment ID to the user.
3. Ensure that no historical data from the previously deleted profile is restored or linked to the new record in your warehouse.

## Supported warehouses

This feature is available for [all warehouses supported by Profiles Sync](/docs/segment/unify/profiles-sync/profiles-sync-setup):

* Snowflake
* Redshift
* BigQuery
* Azure
* Postgres
* Databricks

## Set up Profiles Sync deletions

You can set up Profiles Sync deletions on a per-warehouse basis. This gives you control over which connected warehouses receive deletion requests.

To set up deletions for a warehouse:

1. From your Segment workspace, go to **Unify** > **Profiles Sync**.
2. Select the Profiles Sync connection you want to configure and click the **Settings** tab.
3. Under **Basic settings**, locate the **Sync status** section.
4. Turn on the **Sync Profile deletions to Warehouse** toggle.

> \[!WARNING]
>
> Profiles Sync deletions aren't subject to the core 30-day GDPR [deletion request Service Level Agreement (SLA)](/docs/segment/privacy/user-deletion-and-suppression/#deletion-request-sla). These deletions occur on external, customer-owned infrastructure, so factors such as warehouse availability, concurrent workloads, and provisioning impact processing time.

## Factors that affect deletion speed

The following factors can impact the speed of a deletion request:

* **Very large Profiles Sync tables without indexing**: Without an index to jump directly to matching rows, the delete has to perform a full table scan. Because deletions run against the same warehouse compute as your regular incremental syncs, a long-running deletion job can also compete for that shared compute and delay concurrent incremental syncs.
* **Schemas with an unusually high table count**: The deletion process has to check every table in scope, even ones with no matching rows. Schemas with tens of thousands of tables can mean a single weekly run doesn't finish a full pass, so deletion for that warehouse spreads across multiple weekly cycles.
* **Warehouse-specific limits**: Warehouses that have daily data-processing quotas that your deletion requests can exceed, or that have too little memory, can have long deletion times. For example, BigQuery enforces daily data-processing quotas that can come under pressure if a warehouse has both a large table count and a large backlog of pending deletions. For warehouses hosted on Amazon Relational Database Service, like Postgres, an instance with too little memory or Input/Output Operations Per Second (IOPS) can have disproportionately long deletion times.