Question 1

How does Polytomic write data into ClickHouse?

Accepted Answer

Writes are serialized to Parquet in object storage you configure, then ClickHouse loads them through its own storage table function into a temporary MergeTree before inserting into the target. There is no direct row by row insert path. This is what makes large ETL loads practical, but it does mean destination use requires a staging bucket and the corresponding storage function enabled on your cluster, not just database credentials. Staging runs with multiple concurrent writers and chunked Parquet files.

Question 2

Which table engines can Polytomic write to?

Accepted Answer

Tables Polytomic creates for keyed data use ReplacingMergeTree ordered on the sync key, which is what makes upserts deduplicate correctly. For existing tables the rules are deliberate: any ReplacingMergeTree variant accepts all model write modes, while plain MergeTree, ReplicatedMergeTree, and SharedMergeTree accept append and replace only. Collapsing, Summing, Aggregating and similar engines are refused for model writes, because a retried batch would change the aggregate's meaning rather than being idempotent. That refusal is protecting your data rather than a missing feature.

Question 3

Does Polytomic support change data capture from ClickHouse?

Accepted Answer

No. Reads support full table scans and incremental reads using a tracking field, with the primary key used as a paging tie breaker where one is available. There is no change stream reader, which is expected for an analytical store rather than a transactional one. Incremental reads also do not capture deletes and only see rows whose tracking value advances. Where change data capture matters, it belongs on the transactional systems feeding ClickHouse rather than on ClickHouse itself.

Question 4

How are ClickHouse specific types handled?

Accepted Answer

On read, LowCardinality and Nullable wrappers are unwrapped recursively, typed arrays are preserved, Map values are read as objects, and DateTime64 is read as a datetime with its declared timezone applied. On write, scalar columns are generally nullable, arrays become non null containers because ClickHouse forbids nullable composites, and objects become native JSON on ClickHouse 24.8 and later, falling back to String on older servers. Worth knowing that Polytomic does not create LowCardinality columns, and maps are written as JSON rather than a native ClickHouse Map.

Question 5

Why do I still see duplicate rows right after a sync?

Accepted Answer

ReplacingMergeTree deduplicates asynchronously in ClickHouse, so immediately after a load both the old and new version of a row can be present until a merge runs. This is ClickHouse behavior rather than a sync problem, and querying with FINAL or a suitable aggregation gives the deduplicated view. Polytomic offers an optimize after sync option that runs OPTIMIZE FINAL for you, but it defaults to off deliberately because ClickHouse itself discourages running it routinely on large tables.

ClickHouse

Perfect pairings

Full bidirectional ETL

Optimized for scale

ReplacingMergeTree aware

Example workflows

What you can sync

From ClickHouse

To ClickHouse

How it works

How to set up

Frequently asked questions

Why teams choose Polytomic

No engineering required

Flexible data modeling

Handles scale automatically

Start syncing your data with ClickHouse in minutes

More integrations beyond ClickHouse