...
Databases | Open Source | C++ APIs | Low Latency | Key-Value Storage | Embedded database with on-disk storage mode | In-Memory (Caching) Capabilities | Note |
---|---|---|---|---|---|---|---|
Aerospike | |||||||
Berkeley DB (one of the best) | Developed by Oracle Inc. Support APIs for multiple programming languages. Support many Operating systems as the server. One of the oldest and developed in the year 1994. | ||||||
Redis | only In-memory capabilities. Can only use it as cache store so cannot store data larger than RAM size. | One of the best but cannot store big volumes of data larger than RAM hence cannot be used for our purpose. | |||||
LevelDB | Developed by Google Inc. IoS is not supported as a server operating system. Developed in 2011. | ||||||
RocksDB (also very much recommended) | Developed by Facebook Inc. Developed in 2013. Only supports APIs in language C++ and Java. | ||||||
LMDB (Very high performant) | |||||||
BadgerDB | When Badger is running in in-memory mode, all the data is stored in the memory. Reads and writes are much faster in in-memory mode, but all the data stored in Badger will be lost in case of a crash or close. Badger doesn't support on-disk and in-memory mode together. | ||||||
Riak KV | |||||||
Amazon DynamoDB | |||||||
SQLite (Not very good performance) | Does not guarantee domain integrity. SQLite works great as the database engine for most low to medium traffic. |
It primarily depends on your requirements, as a rule of thumb:
* If your workload is random-writes heavy, choose lsm (RocksDB/LevelDB)
* If your workload is serial-writes heavy, both are similar
* If your workload is read-heavy (random or not) go for lmdb
|