Alex’s research labOpen questions. Reproducible work.

Open research / Open

Less expensive LSM-tree compaction

Can compaction policies reduce write amplification under changing workloads while respecting read, space and tail-latency constraints?

#storage#lsm-trees#compaction

The question

Can compaction policies reduce write amplification under changing workloads while respecting read, space and tail-latency constraints?

This is a proposed research direction. No novel algorithm, completed benchmark or performance gain is claimed.

Why it matters

Embedded databases and streaming state backends could reduce I/O and write stalls.

Search space

File selection, merge timing, level sizing and workload-aware policy switching.

What would count as progress?

  • Correct reads and recovery
  • write/read/space amplification
  • write stalls
  • p99 latency
  • policy overhead.

A useful result improves a measured trade-off against strong baselines on held-out workloads, with reproducible code and documented limitations.

Baselines and boundaries

Compare tuned leveled and universal compaction. Include long steady-state runs, deletes, range scans and workload shifts; do not hide deferred work beyond the benchmark horizon.

Starting reference

Where you could contribute

Help define representative, legally shareable workloads; critique the correctness contract; implement baselines; propose candidates; or reproduce measurements. Negative results and failure cases are useful contributions.

A detailed research brief is being prepared. Access requests will become available when that brief and the request service are ready.

Think out loud

A discussion for this problem.

Questions, alternative approaches and thoughtful critiques are welcome. GitHub sign-in is needed to post. This discussion is public: do not copy restricted materials or personal data into comments. Loading comments connects to giscus and GitHub.

The discussion thread for this problem has not been opened yet. Please check back once it is linked.