QuasarDB schema change rollback: backup vs dual‑write strategy

Goal: Preserve data when rolling back a QuasarDB schema change

In QuasarDB, a schema change is typically implemented by creating a new table with the desired column set. Because the database lacks transactional DDL or automatic versioning, operators must decide how to roll back if the new schema proves unsuitable.

Constraints and Uncertainty

• QuasarDB does not support in‑place ALTER TABLE; tables are immutable after creation.
• Backup/restore restores a snapshot of the entire cluster but does not reconcile writes that occur after the snapshot.
• Dual‑write (running the application against both the old and new tables) can lead to divergence if one writer fails, and requires explicit cutover logic.
• TTL can auto‑expire old tables, but only after a predetermined window.

Open Questions

1. What is the recommended approach to ensure a safe rollback after a schema change: should we rely on a backup/restore cycle that reverts the entire cluster, or use a dual‑write strategy with an application‑controlled cutover?
2. If we choose backup/restore, how does QuasarDB handle writes to the new table that occurred after the snapshot? Are they lost or merged?
3. When using dual‑write, what best‑practice patterns exist for detecting and reconciling divergent writes between the two tables?