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:
MERGE_DATAPARTSThis 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.
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.
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 , A similar model used in high-performance columnar stores to enable immutability, versioning, and efficient compaction.