Ethereum clients (such as geth, eth, pyethapp, ethereumj, and ethereumH) download the Ethereum blockchain from their peers and then store a copy of it locally, presumably indexed within some sort of database for efficient lookup and retrieval. Other uses for databases within the clients may include storage of the state, tracking of peers, etc.

Which databases are used by the respective clients, and for what reasons have they been selected?

  • 2
    This sounds very broad. Maybe you are interested in the different approaches how the blockchain is stored locally? Could you clarify why you want that for all existing clients?
    – q9f
    Commented Feb 2, 2016 at 1:24
  • 3
    There are big differences in performance, use cases etc. between leveldb, sql, or whatever. I considered asking 5 different questions, and still can, but since I think a single answer can compile the info it made more sense to put it all into one. Commented Feb 2, 2016 at 2:02
  • 1
    For Parity see: ethereum.stackexchange.com/questions/13639/…
    – eth
    Commented Mar 15, 2018 at 1:44

3 Answers 3


Geth uses leveldb. Some of the reasons behind choosing it was:

  • In process database (i.e. I don't need to run an additional software)
  • Native implementation in Go (i.e. cross platform to everything Go supports)
  • Key/value store (i.e. values are arbitrary binary blobs, no schema constraints)
  • Modern data storage (i.e. multiple layers on disk, organized in the background)
  • Proven track record (i.e. many companies and other databases build on top)

However, there are also limitations:

  • Ethereum uses hashes exclusively for identifying anything. However, hashes are uniformly randomly distributed identifiers. Leveldb keeps keys organized "alphabetically" on disk, so accessing values associated with hashes is very expensive. This is mostly felt for the state trie, which is hundreds of thousands of nodes scattered and pointing all over the disk. However, without a specific database modelling the Ethereum trie by design, I don't see how this could be further optimized.
  • Leveldb was originally designed by Google to be a disk backed memory database. As long as most of it can fit into memory, it performs very well, but as more and more disk access is required, performance can degrade. Facebook's RocksDB tries to address some of these issues + multi threaded background compaction, but its still a fairly new thing and being in C makes portability hard.
  • Hi @péter-szilágyi I came across your insightful answer and believe it answers my question as well. Although I am unsure if my question is even formulated correctly. I'm leaving a link to it here in the hopes you come across this and maybe provide some further insight. ethereum.stackexchange.com/q/131943/83226 Commented Jul 29, 2022 at 6:09

Parity is using RocksDB as it's database.

From reading here it seems the reason for choosing it was performance. Faster than LevelDB in their tests.

Lately though they have hit some performance issues and a lot of corruption issues with RocksDB and are developing a proprietary DB to better suit Parity, ParityDB. Progress can be tracked in this issue.


There is a new Java Ethereum client recently released Pantheon from pegasys. It uses RocksDb see implementation. I have been developing with it, it supports clique and synced it with Rinkby and the database currently on disk its less than <30Gb. Its using the rocksdb sst file format read more here *.sst files on disk the code here shows you how simple and accessible the persistence api is. There are many reasons why you would choose RocksDB but not least for the Pantheon devs would be a well developed Java api

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.