01Primary reading list
| Reference | Use it to understand |
|---|---|
| Flink CDC 3.5 · MySQL source | Snapshot/incremental capture, server IDs and source requirements |
| Flink 1.20 · Joins | Regular join updates, retained state and TTL tradeoffs |
| Flink 1.20 · Checkpoints | State recovery and the boundary of checkpoint guarantees |
| Flink 1.20 · Upsert Kafka | Keyed updates, deletes and sink delivery configuration |
| Fluss 0.9 · Lakehouse overview | Tiered storage and union reads |
| Iceberg 1.11 · Flink writes | v2 upserts and primary-key requirements |
| Iceberg 1.11 · Maintenance | Snapshot expiration and orphan-file cleanup as explicit operations |
| ClickHouse · ReplacingMergeTree | Version selection, merge-time behavior and FINAL |
02Declared implementation baseline
These are the versions declared in the repository, not a newly certified compatibility matrix. Some image tags identify a minor line, and the Fluss quickstart image bundles dependencies. Inspect actual image digests and installed JARs for a reproducibility record.
| Component | Declared baseline |
|---|---|
| Flink / Fluss quickstart image | 1.20 / 0.9.1-incubating |
| Flink CDC | 3.5.0 |
| Flink Kafka SQL connector | 3.4.0-1.20 |
| Paimon S3 plugin | 1.3.1 |
| Iceberg Flink runtime | 1.11.0 |
| MySQL | 8.0.40 |
| Kafka broker | 4.3.1 |
| ClickHouse | 26.7 |
03How to read a citation
An upstream document explains a component’s supported semantics. The local SQL shows what this project actually configures. A saved run shows what was observed in a specific environment. Use all three when making a strong claim.
ClickHouse’s linked documentation is maintained continuously, so check behavior against the pinned server version. References were reviewed for this publication on 2026-11-07; upstream pages may change. The lab’s own limitations remain explicit even when a component supports additional features.
04Questions for further work
- How would a fixed input fixture and field-level audit make regression tests more informative?
- What changes are needed to propagate deletes correctly into the serving layer?
- How would durable job recovery, scheduled lake maintenance and explicit time semantics change the operational design?
- How should you compare table formats with the same workload, correctness checks and resource limits?