> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turingdb.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# The DataPart System

> DataParts are the units that allows us to be columnar and have version control

## Merging DataParts

Writes accumulate as multiple immutable DataParts, which keeps ingestion fast. To consolidate them into a single compact part for read-optimized scans, run the `MERGE_DATAPARTS` command against the current graph:

```jsx theme={null}
MERGE_DATAPARTS
```

This merges **all** DataParts of the current head commit into one, dropping tombstoned (deleted) entities along the way. It runs synchronously when you invoke it — today it is a manual maintenance operation, not an automatic background process.

<Note>
  Automatic, policy-driven background merging — compacting hot subgraphs and converging toward compact forms without an explicit command — is on the roadmap. For now, trigger compaction explicitly with `MERGE_DATAPARTS`.
</Note>

Commits **start as multiple data parts for fast ingestion** and, once merged, **converge toward compact forms** for analytical speed.

## Summary

| Feature                       | Benefit                                |
| ----------------------------- | -------------------------------------- |
| Immutable DataParts           | Safe versioning and reuse              |
| Parallel write ingestion      | High-performance batch processing      |
| Shared storage across commits | Lower memory usage, fast snapshots     |
| Merge roadmap                 | Compact layout for ultimate read speed |

TuringDB uses **DataParts** to balance **high-speed writes**, **versioned safety**, and **read-optimized performance**, all in a single, cohesive engine.

## Related Concepts

[ClickHouse: Parts](https://clickhouse.com/docs/parts) ,  A similar model used in high-performance columnar stores to enable immutability, versioning, and efficient compaction.