Capture Deletes

Beta. Capture deletes lets a table's full syncs keep the rows the source has stopped returning, instead of replacing the table and losing them.

Normally a full sync replaces the destination table with the snapshot it just extracted, so a record deleted at the source simply disappears from your warehouse. With Capture deletes turned on, the snapshot is merged into the existing table and every row the snapshot no longer contains is stamped with a _weld_deleted_at timestamp. The row stays queryable, so you can audit what was removed and when, and run point-in-time analysis over data the source no longer has.

Capture deletes is available on only a handful of tables today. It needs a full sync that reads a complete snapshot of the source, which most tables do not, so the option appears on a small fraction of the tables Weld offers. We are adding support table by table — see Which tables support it for where it stands right now.

This is a Beta feature. It is off by default and only changes behavior on the tables you explicitly turn it on for.

Turning it on

Open the table's settings (the cogwheel) in your Data Source configuration and toggle Capture deletes — it sits directly above the History tables option in the same menu. Once enabled, the table shows a Captures deletes label next to its sync mode.

The option only appears on tables that support it, so if you cannot find it on a table, that table cannot capture deletes yet.

Capture deletes is available from the Premium plan and up. See Billing for what each plan includes.

What a row looks like

A row whose record was deleted at the source keeps all of its values and gains a deletion timestamp:

idnamestatus_weld_synced_weld_deleted_at
1Spring SaleENABLED2026-09-15 11:15:00(null)
2Winter SalePAUSED2026-09-14 11:15:002026-09-15 11:15:00

To query only the live records, filter on _weld_deleted_at IS NULL.

A few details worth knowing:

  • The timestamp is recorded once. A row marked on one sync keeps its original _weld_deleted_at through later syncs, so the value is the time the record disappeared rather than the time of the latest run.
  • A record that comes back is unmarked. If the source starts returning a row again, the next sync clears its _weld_deleted_at.
  • Partial runs only speak for what they covered. If a run extracted a subset of the source — for example only some of the ad accounts in a multi-account Google Ads sync — it only reconciles the part it actually read, and leaves the rest of the table untouched.

Which tables support it

Capture deletes is only possible where a full sync reads a complete snapshot of the source and the table has primary keys. That is a small set today, and it is growing:

ConnectorTables
Google AdsThe predefined dimension reports (campaign, ad_group, ad, and similar) together with their bidding strategy and criterion substreams.

Even within Google Ads, two kinds of tables are deliberately left out: time-based reports, which already reconcile per report window, and custom reports built from your own query, whose primary keys come from that query.

Every other connector is on the list to be reviewed table by table. Rather than checking here, the reliable answer is the option itself: it is shown only on the tables that can do it.

Which data warehouses support it

The destination has to be able to merge a snapshot into an existing table, which rules out the file-based ones.

Data warehouseCapture deletes
BigQuery (including Weld-managed BigQuery)✅ Supported
Snowflake✅ Supported
Redshift (including Redshift cluster)✅ Supported
Postgres✅ Supported
MS SQL (including SQL Server on RDS and Azure SQL Database)✅ Supported
MotherDuck✅ Supported
ClickHouse❌ Not supported yet
Databricks❌ Not supported
Amazon S3❌ Not supported

Databricks and Amazon S3 receive files rather than tables Weld maintains, so there is nothing to reconcile a snapshot against. ClickHouse is not supported yet because a table created before its stream had primary keys cannot be merged into safely.

Things to keep in mind

  • Rows marked as deleted stay in the table, so the table keeps growing rather than shrinking when records disappear at the source.
  • Schema changes wait for a full sync you request. A merge cannot apply a schema change the destination cannot express in place, so the table has to be rebuilt — and a rebuild clears the deletion markers. When this happens the table is locked and you are notified, and the change is applied on the next full sync you request yourself.
  • You can clear the markers on purpose. Request a full sync at next run and choose to also clear the captured deletes: the table is replaced rather than merged into, dropping every _weld_deleted_at marker it has accumulated.
  • Other tables are unaffected. Every table you have not turned the option on for keeps replacing its table on a full sync exactly as before.

Configuring it over the API

If you set up syncs with the Weld Connect API or the MCP server rather than in the app, the same setting is soft_delete_enabled on a stream, and both sides of the support question are readable before you turn it on:

  1. soft_delete_supported on each stream returned by the available-streams listing (the get_elt_sync_available_streams endpoint and MCP tool).
  2. supports_soft_deletes on the GET /data_warehouse endpoint, or data_warehouse_supports_soft_deletes from the MCP get_account tool.

Enabling it on a stream or a data warehouse that does not support it — or on a plan that does not include the feature — is rejected with an error explaining why, so the setting never ends up silently doing nothing. To drop the accumulated markers, request a full refresh with clear_soft_deleted_rows set to true.

Was this page helpful?