The storage engine for the committed state index needs to support a single operation: “insert all values with unique
keys, or abort if any key conflict found”. A wide range of solutions could be used for that, from embedded key-value
stores to full-fledged relational databases. However, since we don’t need any extra features a RDBMS provides over a
simple key-value store, we’ll only consider lightweight embedded solutions to avoid extra operational costs.

Most RDBMSs are also generally optimised for read performance (use B-tree based storage engines like InnoDB, MyISAM).
Our workload is write-heavy and uses “random” primary keys (state references), which leads to particularly poor write
performance for those types of engines – as we have seen with our Galera-based notary service. One exception is the
MyRocks storage engine, which is based on RocksDB and can handle write workloads well, and is supported by Percona
Server, and MariaDB. It is easier, however, to just use RocksDB directly.

An embedded key-value store based on log-structured merge-trees (LSM). It’s highly configurable, provides lots of
configuration options for performance tuning. E.g. can be tuned to run on different hardware – flash, hard disks or
entirely in-memory.