# Resumable Remote Compaction

DevFeed: [Resumable Remote Compaction](<https://devfeed.tech/articles/resumable-remote-compaction-22399.md>)

Original publisher: [Read original article](<http://rocksdb.org/blog/2026/05/19/resumable-remote-compaction.html>)

Author: Hui Xiao

Published: 2026-05-19T00:00:00Z

Content type: article

Language: en

Sources: [RocksDB](<https://devfeed.tech/sources/rocksdb.md>)

Topics: [rocksdb](<https://devfeed.tech/topics/rocksdb.md>), [API](<https://devfeed.tech/topics/api.md>), [IO](<https://devfeed.tech/topics/io.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [blog](<https://devfeed.tech/tags/blog.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [encoding](<https://devfeed.tech/tags/encoding.md>), [files](<https://devfeed.tech/tags/files.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [rocksdb](<https://devfeed.tech/tags/rocksdb.md>), [scale](<https://devfeed.tech/tags/scale.md>), [state](<https://devfeed.tech/tags/state.md>), [stateless](<https://devfeed.tech/tags/stateless.md>)

## AI overview

RocksDB's resumable remote compaction adds checkpointing so interrupted compaction jobs can continue from their latest completed output SST instead of restarting from scratch. The article explains checkpoint contents, delta encoding, safety constraints, resume behavior, and configuration requirements.

## Source excerpt

Background RocksDB can offload compaction work to remote workers through the CompactionService API. In this model, the primary RocksDB instance selects the input files and sends a serialized CompactionServiceInput to a worker; the remote worker runs DB::OpenAndCompact(), writes output SSTs to output_directory, and returns a serialized CompactionServiceResult that the primary RocksDB instance installs into its LSM tree. See the Remote Compaction wiki for the full architecture. This lets operators scale compaction throughput with stateless workers while keeping the primary RocksDB instance's CPU and I/O available for serving reads and writes. However, remote compaction jobs can be long-running--sometimes processing hundreds of gigabytes of input. When a worker crashes, gets preempted, or times out, the entire compaction must restart from scratch, wasting all output produced before the interruption and increasing compaction debt on the primary RocksDB instance. How Resumable Remote Compaction Works Resumable remote compaction introduces a checkpoint-and-resume mechanism. During a compaction, the worker periodically saves its progress to the output_directory. If the compaction is interrupted, a subsequent call to OpenAndCompact() with the same output directory can pick up from the last checkpoint rather than starting over. Checkpointing After each output SST file is completed, the worker persists a progress checkpoint to a compaction progress file in the output directory output_directory. The checkpoint records which internal key to resume from and the metadata of all completed output files. Progress records use delta encoding--each record only contains files completed since the last checkpoint--to keep serialization cost linear. The worker skips checkpointing at boundaries where resuming could be unsafe or requires complicated handling: when range deletions span the file boundary or when adjacent output files share the same user key. These constraints ensure that resuming