<p>Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.</p>

<p>Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.</p>

<p>We don't need a server/client architecture, as we can't have multiple applications accessing the database at once anyway: inconsistencies in the database would lead to forking risks (every node in the network needs to make exactly the same judgement about what is valid and invalid).</p>

CC BY-SA 3.0
2017-02-16T04:32:39.237Z
@Pieter Wuille Do you consider that moving from BDB to LevelDB was a correct decision? Or LevelDB is causing major problems that didn't happened with BDB? (ex: file corruption, bugs ...)
Mark Messa
CC BY-SA 3.0
2016-11-09T00:49:01.073Z
Has LMDB been considered?
stefanwouldgo
CC BY-SA 3.0
2016-10-13T11:04:43.120Z
2016-10-13T11:04:43.120Z
Pieter Wuille
<p>Why did Core move from <code>BDB</code> to <code>LevelDB</code>? Why don't they use <code>SQLite</code> or move to <code>Redis</code> now? Is there a technical reason for this choice?</p>

CC BY-SA 3.0
2016-10-12T23:43:24.707Z
The bdb->leveldb change was made to increase speed while validating blocks and during initial block download. Also, doesn't redis require that you load your entire dataset into memory? Pretty painful for a 60GB blockchain.
Nick ODell
CC BY-SA 3.0
2016-10-13T08:22:04.503Z
but redis uses LZF light data compressor , this won't help to reduce the data volume in memory? and i thought leveldb was chosen because it supports high caching data.
Etherkimist
CC BY-SA 3.0
2016-10-13T10:59:01.763Z
LevelDB also supports compression. We explicitly disable it in Bitcoin Core because it does not help (almost all the data in the database consists of uncompressible cryptographic material anyway: hashes, keys, signatures).
Pieter Wuille
CC BY-SA 3.0
2016-10-13T11:05:43.993Z
@Nick We wouldn't store the entire blockchain in the database anyway.
Pieter Wuille
CC BY-SA 3.0
2016-10-13T11:07:10.067Z
as i know we store only the blocks and the state of validation < blockchain
Etherkimist
CC BY-SA 3.0
2016-10-13T11:14:12.413Z
Not even the blocks. Those are stored on disk, but not in a database. The only data of significance in the database is the UTXO set.
Pieter Wuille
<bitcoin-core-development><utxo><database><leveldb>
Why is Bitcoin Core using LevelDB instead of Redis or SQLite?
Etherkimist
# Why is Bitcoin Core using LevelDB instead of Redis or SQLite?

(Asked by: username_0 on 2016-10-12)

Why did Core move from `BDB` to `LevelDB`? Why don't they use `SQLite` or move to `Redis` now? Is there a technical reason for this choice?

**Tags:** bitcoin-core-development, utxo, database, leveldb

> **Comments:**
> **username_1**: The bdb->leveldb change was made to increase speed while validating blocks and during initial block download. Also, doesn't redis require that you load your entire dataset into memory? Pretty painful for a 60GB blockchain.  
> **username_0**: but redis uses LZF light data compressor , this won't help to reduce the data volume in memory? and i thought leveldb was chosen because it supports high caching data.  
> **username_2**: LevelDB also supports compression. We explicitly disable it in Bitcoin Core because it does not help (almost all the data in the database consists of uncompressible cryptographic material anyway: hashes, keys, signatures).  
> **username_2**: @Nick We wouldn't store the entire blockchain in the database anyway.  
> **username_0**: as i know we store only the blocks and the state of validation < blockchain  
> **username_2**: Not even the blocks. Those are stored on disk, but not in a database. The only data of significance in the database is the UTXO set.  

---

## 1 answers

### Answer by username_2 on 2016-10-13. Score: 14 | Accepted answer

Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.

Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.

We don't need a server/client architecture, as we can't have multiple applications accessing the database at once anyway: inconsistencies in the database would lead to forking risks (every node in the network needs to make exactly the same judgement about what is valid and invalid).

> **Comments:**
> **username_4**: Has LMDB been considered?  
> **username_3**: @username_2 Do you consider that moving from BDB to LevelDB was a correct decision? Or LevelDB is causing major problems that didn't happened with BDB? (ex: file corruption, bugs ...)  

---

