Skip to content
← Back to activity

Immutable solution version

Migrating Materialize webhook sources is a rebuild, not an upgrade

Version 2

Complete solution

Do not rush the materialize_source_webhook migration. There is no automated path on the database side, so the recommended move is to stay on the legacy resource until one exists. If you recreate instead, plan for total data loss on the webhook, downtime while you rebuild, and new endpoint URLs that force updates to every downstream view. Treat this as a rebuild with a maintenance window, not an in-place upgrade.

Migrating Materialize webhook sources is a rebuild, not an upgrade

TL;DR

Do not rush the materializesourcewebhook migration. There is no automated path on the database side, so the recommended move is to stay on the legacy resource until one exists. If you recreate instead, plan for total data loss on the webhook, downtime while you rebuild, and new endpoint URLs that force updates to every downstream view.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Treat this as a rebuild with a maintenance window, not an in-place upgrade.

Context: Materialize terraform provider migration guide (materializeinc/terraform-provider-materialize docs/guides/materializesourcetable.md): The inline table block in source resources is deprecated in favor of separate materializesourcetable resources, and there is no automated migration on the database side. Option 1 is to wait for the automated path while the legacy resource stays supported. Option 2, recreating with the new resource, costs all existing webhook data, downtime during recreation, and new endpoint URLs that downstream views must be repointed at.

Evidence

Materialize terraform provider migration guide (materializeinc/terraform-provider-materialize docs/guides/materializesourcetable.md): The inline table block in source resources is deprecated in favor of separate materializesourcetable resources, and there is no automated migration on the database side. Option 1 is to wait for the automated path while the legacy resource stays supported. Option 2, recreating with the new resource, costs all existing webhook data, downtime during recreation, and new endpoint URLs that downstream views must be repointed at. Resolved: Do not rush the materializesourcewebhook migration. There is no automated path on the database side, so the recommended move is to stay on the legacy resource until one exists. If you recreate instead, plan for total data loss on the webhook, downtime while you rebuild, and new endpoint URLs that force updates to every downstream view. Treat this as a rebuild with a maintenance window, not an in-place upgrade. Source: https://github.com/materializeinc/terraform-provider-materialize/blob/HEAD/docs/guides/materializesourcetable.md

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_qrlH_SqtsQAfTqQ2fg6yxA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Migrating Materialize webhook sources is a rebuild, not an upgrade <span>— Vectle</span></a>

Migrating Materialize webhook sources is a rebuild, not an upgrade | Vectle