Summary

There have been a few discussions already surrounding the topic. This is an issue that tries to capture the current landscape and offer some guidance towards heading forwards. Essentially the crux of the topic is more of a question: How involved does Tendermint want to be with the database layer that it operates above? The core value of Tendermint resides in BFT state machine replication. This means modules such as consensus, p2p, mempool and so forth. Because of this focus, we should slowly reduce the large maintenance surface area that Tendermint currently holds with the database layer. In its place, we should look to settle for leading and established technologies that we can leverage off.

Specifically that points three issues:

• Reduce the amount of databases supported, eventually converging to a singe database that best fits Tendermint's use case.
• Implement an established query engine to use for the Tx Indexer (such as sqlite or postgres)
• Reassess the write ahead log

Converge to a single database

Currently, tm-db supports five different databases (GoLevelDB, LevelDB, BoltDB, RocksDB and BadgerDB). This offers a greater degree of flexibility to application developers but it's not clear whether such flexibility provides the necessary gain to offset the maintenance burden of providing continual support. Having this wrapped around a common interface restricts that amount of value we can extract from each of the respective databases and means that we can't exploit some of the invariants of Tendermint (append only, high write volume and so forth).

In order to move forward, we will need to undergo a process of comparing the various technologies out there, writing them all up in a document, conversing with SDK and other users and eventually reach a consensus on the db engine of choice.

Following from this, another document, this time more implementation focused and most likely an ADR, will need to be sketched out. Given a single database engine we will need to review how it should now interface with Tendermint. This could likely lead to a large rewrite of some of the internal code. Another question that would arise then would be: Do we want to use only one or perhaps two databases instead of four different ones. This may offer greater atomicity of transactions.

Implement an established query engine for the Tx Indexer

The Tx Indexer is a secondary index to query and find particular Txs. Whilst the current implementation of a kv store suffices, there is already a wealth of highly performant query engines that we should consider using (sqlite, postgres). This will allow us to piggy back off the latest technology whilst only needing to maintain a much smaller codebase (the wrapper around the engine).

Reassess the write ahead log

The WAL, records all messages that the consensus engine produces so that in the event of a crash, when the node starts up again it can replay all the messages back to the point of failure. This is another, although perhaps smaller, area where we might be able to reduce the amount of code we need to upkeep. It seems, at least to me, that we only need a write ahead log for the votes that we sign in order to prevent double signing yet for everything else we could rely on the existing "catch up" mechanism to receive all the votes and blocks that have happened since the crash to restore the node to the most recent height.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned