Hello, did you find any interesting solution ? Do ReplacingMergeTree works well for you ?

The 4.5x jump is too big to be pure partitioning overhead by itself, so my first suspicion is that ReplacingMergeTree isn't actually collapsing anything and you're just paying partition tax on top of undeduplicated data.

Two things determine whether ReplacingMergeTree collapses a row. The merge has to happen (OPTIMIZE ... FINAL forces this, but only within a partition, it never merges across partition boundaries), and the rows have to match on the full ORDER BY key, not just look like duplicates to you. If the ORDER BY key on the new table includes anything with per-insert cardinality, an autoincrement id, an ingestion timestamp, anything that varies between the "duplicate" writes, then no two rows will ever share a sort key and the merge has nothing to collapse. Worth checking: is the ORDER BY on the ReplacingMergeTree table identical to what you'd consider the natural key of a record, and does whatever is driving the duplicates sit outside that key?

Second thing, run this before speculating further:

SELECT partition, count() AS parts, sum(bytes_on_disk) AS bytes, sum(rows) AS rows
FROM system.parts
WHERE table = '<your table>' AND active
GROUP BY partition
ORDER BY parts DESC
LIMIT 20

If toYYYYMM(fetched) is producing far more partitions than you expect, garbage timestamps outside your real ingestion range will do this silently, you'll see it immediately as a long tail of tiny partitions. Each partition merges independently, so a partition with a handful of rows still carries the fixed per-part overhead (index granules, mark files, minimum compressed block size), and that adds up fast across thousands of partitions in a way that dwarfs the partitioning-vs-no-partitioning tradeoff at a reasonable partition count.

My guess is the ORDER BY key isn't actually identifying your duplicates. Partitioning is real overhead, but it doesn't explain a 4.5x blow-up on its own at a sane partition count. If system.parts shows a normal partition count, dozens rather than thousands, and OPTIMIZE FINAL still leaves it huge, then it's the ORDER BY mismatch, and no amount of merging will fix that until the key changes.