JDBC Driver ↔ ReplicatedMergeTree: Zero‑Downtime Schema Evolution via Online ALTER or Drop‑and‑Swap

Goal

Upgrade a small Java application’s ClickHouse schema without service interruption. The application uses the official JDBC driver and a ReplicatedMergeTree table that must stay writable during the change.

Constraints

• ALTER TABLE ADD COLUMN with a default value temporarily locks writes on the shard.
• Drop‑and‑swap requires a brief window where the old table name is dropped and the new one is created.
• JDBC connection pools may cache metadata and need to refresh to see the new table name.

Unresolved Decision

How the JDBC driver and the application handle the transient lock and rename window, and what impact materialized views have on write amplification during the migration.

Questions

1. Does the ClickHouse JDBC driver automatically detect and retry queries that fail due to the write lock acquired during an online ALTER on a ReplicatedMergeTree?
2. When performing a drop‑and‑swap, how long can the pool retain the old table name before SELECTs fail, and what pool‑refresh strategy ensures continuous availability?
3. What is the measurable write‑amplification overhead introduced by using a materialized view to keep the new schema in sync during a high‑write workload?