> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Schema changes propagation support

> Page describing schema change types detectable by ClickPipes in the source tables

ClickPipes for MySQL can detect schema changes in the source tables and, in some cases, automatically propagate the changes to the destination tables. The way each DDL operation is handled is documented below:

[//]: # "TODO Extend this page with behavior on rename, data type changes, and truncate + guidance on how to handle incompatible schema changes."

| Schema Change Type                                                                  | Behaviour                                                                                                                                                                                                                  |
| ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Adding a new column (`ALTER TABLE ADD COLUMN ...`)                                  | Propagated automatically. The new columns will be populated for all rows replicated after the schema change                                                                                                                |
| Adding a new column with a default value (`ALTER TABLE ADD COLUMN ... DEFAULT ...`) | Propagated automatically. [Supported defaults](#default-values-for-added-columns) are also added to the ClickHouse column, so they apply to rows already in ClickHouse as well as rows replicated after the schema change. |
| Dropping an existing column (`ALTER TABLE DROP COLUMN ...`)                         | Detected, but **not** propagated. The dropped columns will be populated with `NULL` for all rows replicated after the schema change                                                                                        |

<Note>
  Column additions during snapshot are currently not supported. The suggested workaround is to perform snapshots before or after planned schema changes, or, if the ClickPipe is already failing, to manually add a column of the appropriate type to the destination table.
</Note>

<h2 id="default-values-for-added-columns">
  Default values for added columns
</h2>

For an added column, ClickPipes propagates a default only when it can translate the value safely to ClickHouse. When a default is propagated, ClickHouse uses it when reading data parts that predate the new column. As a result, rows already present in ClickHouse receive the source default without a full table refresh.

ClickPipes propagates literal integer, decimal, and floating-point values; booleans; simple string and date values; and enum or set values when the MySQL server provides full binlog row metadata. It rewrites string literals using ClickHouse-compatible quoting.

ClickPipes intentionally omits defaults that are not portable literals, including `NULL`, bit literals, function calls such as `CURRENT_TIMESTAMP`, `NOW()`, or `UUID()`, and string values containing backslashes or control characters. The column is still added, but ClickHouse uses its normal type default for parts that predate the column. A full table refresh is required if those existing rows must contain the source default.

ClickPipes propagates defaults only as part of `ALTER TABLE ADD COLUMN`. Later operations that change or remove a column default are not propagated to ClickHouse.

<h3 id="mysql-5-limitations">
  MySQL 5.x limitations
</h3>

MySQL versions older than [8.0.1](https://dev.mysql.com/blog-archive/more-metadata-is-written-into-binary-log/) do not include full column metadata in the binlog (`binlog_row_metadata=FULL`), so ClickPipes tracks columns by ordinal position. This means:

* **Adding a column at the end** (`ALTER TABLE ADD COLUMN ...`) is supported.
* **Any DDL that shifts column positions** will cause the pipe to raise an error, because ordinal positions can no longer be reliably mapped. This includes:
  * `ALTER TABLE DROP COLUMN ...`
  * `ALTER TABLE ADD COLUMN ... AFTER ...` / `FIRST`
  * `ALTER TABLE MODIFY COLUMN ... AFTER ...` / `FIRST`
  * `ALTER TABLE CHANGE COLUMN ... AFTER ...` / `FIRST`

If you hit this error, you will need to resync the pipe.