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

# Avoid `OPTIMIZE FINAL`

> Page describing why you should avoid the OPTIMIZE FINAL clause in ClickHouse

ClickHouse tables using the **MergeTree engine** store data on disk as **immutable parts**, which are created every time data is inserted.

Each insert creates a new part containing sorted, compressed column files, along with metadata like indexes and checksums. For a detailed description of part structures and how they're formed we recommend this [guide](/concepts/core-concepts/parts).

Over time, background processes merge smaller parts into larger ones to reduce fragmentation and improve query performance.

<Image img="/images/bestpractices/simple_merges.png" size="md" alt="Simple merges" />

While it's tempting to manually trigger this merge using:

```sql theme={null}
OPTIMIZE TABLE <table> FINAL;
```

**you should avoid the `OPTIMIZE FINAL` operation in most cases** as it initiates
resource intensive operations which may impact cluster performance.

<Info>
  **OPTIMIZE FINAL vs FINAL**

  `OPTIMIZE FINAL` isn't the same as `FINAL`, which is sometimes necessary to use
  to get results without duplicates, such as with the `ReplacingMergeTree`. Generally,
  `FINAL` is okay to use if your queries are filtering on the same columns as those
  in your primary key.
</Info>

<h2 id="why-avoid">
  Why avoid?
</h2>

<h3 id="its-expensive">
  It's expensive
</h3>

Running `OPTIMIZE FINAL` forces ClickHouse to merge **all** active parts into a **single part**, even if large merges have already occurred. This involves:

1. **Decompressing** all parts
2. **Merging** the data
3. **Compressing** it again
4. **Writing** the final part to disk or object storage

These steps are **CPU and I/O-intensive** and can put significant strain on your system, especially when large datasets are involved.

<h3 id="it-ignores-safety-limits">
  It ignores safety limits
</h3>

Normally, ClickHouse avoids merging parts larger than \~150 GB (configurable via [max\_bytes\_to\_merge\_at\_max\_space\_in\_pool](/reference/settings/merge-tree-settings#max_bytes_to_merge_at_max_space_in_pool)). But `OPTIMIZE FINAL` **ignores this safeguard**, which means:

* It may try to merge **multiple 150 GB parts** into one massive part
* This could result in **long merge times**, **memory pressure**, or even **out-of-memory errors**
* These large parts may become challenging to merge, i.e. attempts to merge them further fails for the reasons stated above. In cases where merges are required for correct query time behavior, this can result in undesired consequences such as [duplicates accumulating for a ReplacingMergeTree](/concepts/features/operations/insert/deduplication#using-replacingmergetree-for-upserts), diminishing query time performance.

<h2 id="let-background-merges-do-the-work">
  Let background merges do the work
</h2>

ClickHouse already performs smart background merges to optimize storage and query efficiency. These are incremental, resource-aware, and respect configured thresholds. Unless you have a very specific need (e.g., finalizing data before freezing a table or exporting), **you're better off letting ClickHouse manage merges on its own**.