RocksDB gets re-compiled on every file change (reason why + workaround)

### Description Hi, I'm using the RocksDB feature, and noticed that RocksDB gets re-compiled on every file change, resulting in 100% of all my CPU cores being used for several minutes, making my system unresponsive. The reason is, that `rust-rocksdb` defaults to using a vendored version of RocksDB (i.e. not using the pre-compiled version, that might be installed on the system), which seems to result in a re-compilation on every file change. `rust-rocksdb` uses the system RocksDB if `ROCKSDB_LIB_DIR` points to the directory where it is installed (`SNAPPY_LIB_DIR` can be used for `snappy`) – however it's not great to have to specify those environment variables always and everywhere (IDE, command line, etc.). My workaround is to define these variables in [.cargo/config.toml](https://doc.rust-lang.org/cargo/reference/config.html): ```toml [env] ROCKSDB_LIB_DIR = "/usr/lib/" SNAPPY_LIB_DIR = "/usr/lib/" ``` Now every Cargo instance that runs within the project directory has `ROCKSDB_LIB_DIR` and `SNAPPY_LIB_DIR` set. I'm opening this issue mostly for visibility / so nobody else has to waste time figuring out what is going on and how to fix it (I couldn't find anything in this repo). Feel free to just close the issue. I'm not closing it myself, in case you want to add the above workaround somewhere to the documentation (which would be the right thing to do, I think). PS: See the following issue for more information: https://github.com/rust-rocksdb/rust-rocksdb/issues/310 ### Is there an existing issue for this? - [X] I have searched the existing issues ### Code of Conduct - [X] I agree to follow this project's Code of Conduct

GitHubToolOtherSource
0Sign in to voteCopy link

FL score

28

out of 100

Verdict

SKIP

medium confidence

Competition

No competitor data yet

Trend

No signal yet

A GitHub issue requesting documentation for a known workaround to RocksDB recompilation in Rust projects.

The pain

Developers using rust-rocksdb experience system-wide unresponsiveness when the vendored RocksDB recompiles on every file change, consuming all CPU cores for minutes. The pain is real but affects only developers who have not set environment variables that point to system-installed RocksDB libraries.

The gap

The gap is purely informational. The technical solution exists (set ROCKSDB_LIB_DIR and SNAPPY_LIB_DIR in .cargo/config.toml). No new tool, service, or product is needed. The rust-rocksdb library already supports this. The only missing piece is documentation or a note in the project README.

Build angle

You could build a Rust development environment setup tool that auto-detects system libraries and generates .cargo/config.toml files, but this solves a symptom of a much larger problem (Rust build configuration complexity) and would compete against existing solutions like rustup and cargo-edit.

Strengths

  • The problem is real and causes measurable developer friction.
  • The solution is simple and reproducible.
  • The issue reporter has already validated the fix works.

Risks

  • This is a documentation request, not a business opportunity.
  • The rust-rocksdb maintainers could close this by adding one paragraph to their README.
  • The addressable market is developers using RocksDB in Rust, a subset of a subset.
  • No one would pay for a product that solves this when the fix is free and takes 30 seconds to implement.
  • Building a general Rust build configuration tool would face competition from established tooling and would need to solve much broader problems to justify its existence.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “RocksDB gets re-compiled on every file change (reason why + workaround)”.

Open FlyBot