“atomic swap” usually means performing a schema rename (or object-level rename) in a way that:
- ✅ Happens instantly (or appears instantaneous to consumers),
- ✅ Is all-or-nothing (no partial state),
- ✅ Minimizes downtime and removes risk of inconsistent data.
🔁 What exactly is swapped?
In most databases (like BigQuery, Snowflake, Redshift), the “atomic swap” is done by renaming schemas or tables:
| Step | Example |
|---|---|
| Active schema | analytics_prod |
| New build schema | analytics_prod__temp |
| Swap action | Rename analytics_prod → analytics_prod__backup Rename analytics_prod__temp → analytics_prod |
| Result | All consumers now point to the new version, instantly |
🧠 Why is it called “atomic”?
The term “atomic” comes from database theory, meaning an operation that is:
- Atomic: not interruptible and not partially applied.
- Think like a light switch: either it’s ON or it’s OFF — no in-between.
This guarantees that no query ever sees an incomplete transition.
🔍 Alternative meanings in other systems
In some systems, atomic swaps might be:
- Switching views instead of schemas (
CREATE OR REPLACE VIEW), - Swapping pointers (e.g. symbolic links),
- Or even changing permissions or routing logic.
But in dbt blue-green deployment, it typically means:
👉 Rename the temporary schema to the production schema name.