The recent automated upgrade of Tendermint's import of tm-db to v0.6.7 failed. Although the API for the Go library is compatible, v0.6.7 depends on a fork (I think?) of the underlying C library code for RocksDB, and that breaks the build automation Tendermint Core currently uses.

The breakage only occurs when the rocksdb build tag is enabled in TENDERMINT_BUILD_OPTIONS, but that currently affects our end-to-end tests, which build with all supported tags.

Action item: Decide how to deal with this conflict.

Discussion

There are several choices for how we could resolve this, including:

1. Skip v0.6.7 and remain pinned at v0.6.6.
2. Update the build automation to fetch and compile the patched C library.
3. Remove RocksDB support from Tendermint Core.

Option (1) is the least work, and in light of our intentions documented in RFC 001, this may be the simplest practical solution for now. One drawback is that if we need to patch tm-db to fix a bug or security issue, we'd then have to confront this again. Given, however, that the rate of updates to tm-db has been very low, this may be a reasonable gamble.

Option (2) is the most work, and provides dubious return on investment. While RocksDB is favoured by some operators for application storage, it does not provide any clear advantages for use by the consensus engine's internal storage. On the other hand, if we are not going to upgrade to the latest tm-db version, leaving the old dependency in place may expose users to weird link-time issues, where the C libraries export different symbols. The latter is the main reason to consider (2) over (1).

Option (3) requires a few changes, and is a breaking change for existing use. For master this is not a concern, but will also need to address this issue for all supported release branches as well. Doing this would resolve the C link-time risk, and would still permit applications to build their own custom RocksDB integration. What would break is any node that might have been using RocksDB as its consensus storage. We have some reason to believe such usage is rare (if any), but it's a question that deserves a clear answer.

Recommendation

I believe (3) is our best option, and (1) is a reasonable alternative. I do not think we should implement (2). Note that neither (1) nor (3) prevents applications from continuing to use the RocksDB backend in tm-db, this is only about what the consensus engine uses.