Audit this MERGE / upsert as if silent key collisions would corrupt a finance or operations table. Do not treat dialect MERGE as atomic or idempotent until the match keys, predicates, and concurrent writers are proven.
Warehouse and dialect: [Snowflake / BigQuery MERGE / Redshift / Databricks / Postgres]
Target table grain and unique key: [definition]
Source of changes: [staging table, stream, file, CDC]
Match condition and extra predicates: [WHEN MATCHED / NOT MATCHED]
Delete / tombstone handling: [hard delete, soft delete, none]
Concurrent writers: [live pipeline plus backfill, or single writer]
Current SQL:
[Paste MERGE, MERGE INTO, or MERGE-equivalent INSERT/UPDATE]
Observed symptoms: [duplicates, missed updates, flip-flopping values, or none]
Produce:
1. Explicit grain, uniqueness invariant, and what "same row" means
2. Match-key analysis including NULLs, type coercion, and unstable hashes
3. WHEN MATCHED / NOT MATCHED coverage for inserts, updates, no-ops, and deletes
4. Race analysis for two writers, delayed files, and overlapping backfills
5. Non-deterministic UPDATE risks: many-to-one matches, unordered source rows
6. Dialect-correct rewritten SQL that is restart-safe
7. Fixtures for duplicate keys, late updates, tombstones, and empty batches
8. Post-merge validation queries for uniqueness, row counts, and sampled diffs
9. Locking, clustering, and micro-partition implications of the rewrite
10. Go/no-go with residual risks labeled P0-P2
State assumptions. Never recommend MERGE without a uniqueness test on both source and target after the write.