Choosing a RocksDB Compaction Style for Your Workload
Guide to picking Level, Universal, or FIFO compaction in RocksDB based on read/write ratio, latency, and storage constraints, with sample C++/Java code and verification steps.
Loading…
ReadMeFeed / Community knowledge
Rocksdb
Real questions. Useful conversations. Find the people who know your stack.
Rocksdb
Databases & messaging · #rocksdb
Diagnosing and Resolving RocksDB Write Stall Conditions
Learn how to spot RocksDB write stalls, diagnose their root causes with specific properties, apply targeted fixes, and know when to escalate.
Configuring RocksDB Write-Ahead Log for Durability‑Throughput Trade‑offs
Learn how to tune RocksDB's WAL sync behavior to improve write throughput while understanding the durability window you may lose.
Isolate Workloads in RocksDB Using Column Families with Custom Memtable and Compaction Settings
Learn how to configure RocksDB column families to give different workloads their own memtable, write buffer, and compaction settings while sharing a single DB instance.
TTL expiration behavior with merge operators in RocksDB compaction
Goal Determine whether RocksDB removes TTL‑expired keys before applying a merge operator during compaction, and what impact this interaction has on write amplification and memtable usage. Constraints / Uncertainty The documentation states that TTL expiration is performed lazily during compaction or reads, but does not specify the order relative to merge‑oper
RocksDB Block Cache memory growth with shared Column Families
RocksDB allows multiple Column Families to share a single Block Cache to optimize memory utilization. While the cache is governed by a size limit and an LRU eviction policy, the interaction between the Block Cache and MemTable memory limits can create ambiguity regarding the total process memory footprint. Under high concurrency and heavy random read pattern
How does RocksDB ensure that retrying a WriteBatch after a write stall does not create duplicate writes in the WAL?
Determine whether RocksDB's internal retry loop for WriteBatch operations guarantees that no duplicate writes are persisted to the WAL or applied to the memtable when a write stall (e.g., memtable full) triggers a retry. Assume default WAL enabled, sequence numbers are incremented on each retry, and recovery replays only the highest sequence number per key.
RocksDB WriteBatch and WAL recovery duplication
RocksDB utilizes WriteBatch to ensure atomicity, ensuring that a group of operations is applied as a single unit. While this prevents partial updates, the system relies on the Write-Ahead Log (WAL) for durability and recovery after a crash. A design uncertainty exists regarding the interaction between the WAL and the memtable during recovery. Specifically, i
RocksDB write_buffer_size and max_write_buffer_number tuning under a fixed memory budget
RocksDB's documented defaults set write_buffer_size to 64 MiB per column family and max_write_buffer_number to 2. That is adequate for light local workloads, but under sustained production write traffic the memtable fills quickly, flushes queue up, and the write path stalls once the buffer count limit is reached. The unresolved decision is how much memory to