Fix "Too many parts"

Code: 252. DB::Exception: Too many parts (N). Merges are processing significantly slower than inserts means ClickHouse has stopped accepting new INSERTs into a table because the background merge process can't combine data parts as fast as they're being created. It hits everyone from small side projects to large production clusters — it's the single most common MergeTree failure.

Why it happens

Every INSERT creates at least one new data part per partition. Background merges continuously combine small parts into larger ones so reads stay fast. When inserts outpace merges, the part count climbs until ClickHouse protects itself:

• Frequent small inserts. Row-at-a-time or micro-batch inserts (application-side "insert on every event") create far more parts than the merge scheduler can absorb.
• Over-partitioned tables. A partition key with too many distinct values (for example PARTITION BY (toDate(ts), user_id) instead of just toDate(ts)) multiplies the number of parts per insert.
• Merges genuinely falling behind. Slow disks, an undersized merge pool, or a burst of large mutations can make merges the bottleneck even with a sane insert pattern — see Merges slower than inserts for that root cause.

Diagnose

Find which tables are closest to the throttle. ClickHouse starts delaying inserts at parts_to_delay_insert (default 3000 active parts in one partition) and rejects them outright at parts_to_throw_insert (default 3000 as well on recent versions, historically higher):

SELECT
    database,
    table,
    count() AS active_parts,
    max(modification_time) AS last_part_created
FROM system.parts
WHERE active
GROUP BY database, table
ORDER BY active_parts DESC
LIMIT 20;

active_parts above 1,000–2,000 for any single table is worth investigating before it becomes an outage. To see whether merges are keeping pace, compare recent insert volume against merge volume from system.part_log:

SELECT
    event_type,
    count() AS events,
    sum(rows) AS total_rows
FROM system.part_log
WHERE table = 'your_table' AND event_time > now() - INTERVAL 1 HOUR
GROUP BY event_type;

A NewPart count far higher than MergeParts over the same window confirms inserts are outrunning merges.

Fix

See it in chmonitor

The Tables page shows live active-part counts per table, sorted so the tables closest to the throttle surface first — no need to run the query above by hand. Try it on the live demo.

Related