<p>The fork serves two purposes:</p>

<ul>
<li><p>Local modifications that are hard to bring upstream:</p>

<ul>
<li>Windows support (which is partially based on the existing Windows port, but needed changes for building in MinGW)</li>
<li>Removal of compression support, as it doesn't help, and complicates the build.</li>
</ul></li>
<li>Strict control over changes. Given the previous experience with the BDB to LevelDB changeover that caused a fork in the network, it is wise to not use system-wide installed versions of the library. Hypothetically, even if a change is a bug fix from the point of view of LevelDB, we may want to maintain the buggy behaviour to prevent a fork in the network, depending on the bug.</li>
</ul>

CC BY-SA 3.0
2016-02-16T05:04:34.497Z
2016-02-16T05:04:34.497Z
Pieter Wuille
<p>Since 0.8 bitcoind uses LevelDB for the storage of the UTXO set in <code>chainstate/</code> and the block index in <code>blocks/index/</code>. On github special branch of LevelDB can be found:</p>

<p><a href="https://github.com/bitcoin/leveldb" rel="noreferrer">https://github.com/bitcoin/leveldb</a></p>

<p>What reasons made LevelDB the best choice for key-value storage compared to other embedded database solutions? How does bitcoind's own LevelDB fork differ from the official version?</p>

<database><utxo><leveldb>
Why does bitcoind use a fork of LevelDB for key-value storage?
Felix Weis
# Why does bitcoind use a fork of LevelDB for key-value storage?

(Asked by: username_0 on 2016-02-15)

Since 0.8 bitcoind uses LevelDB for the storage of the UTXO set in `chainstate/` and the block index in `blocks/index/`. On github special branch of LevelDB can be found:

<https://github.com/bitcoin/leveldb>

What reasons made LevelDB the best choice for key-value storage compared to other embedded database solutions? How does bitcoind's own LevelDB fork differ from the official version?

**Tags:** database, utxo, leveldb


---

## 1 answers

### Answer by username_1 on 2016-02-16. Score: 7 | Accepted answer

The fork serves two purposes:

* Local modifications that are hard to bring upstream:

  + Windows support (which is partially based on the existing Windows port, but needed changes for building in MinGW)
  + Removal of compression support, as it doesn't help, and complicates the build.
* Strict control over changes. Given the previous experience with the BDB to LevelDB changeover that caused a fork in the network, it is wise to not use system-wide installed versions of the library. Hypothetically, even if a change is a bug fix from the point of view of LevelDB, we may want to maintain the buggy behaviour to prevent a fork in the network, depending on the bug.


---

