<p>There are basically four pieces of data that are maintained:</p>

<ul>
<li><code>blocks/blk*.dat</code>: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.</li>
<li><code>blocks/index/*</code>: this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.</li>
<li><code>chainstate/*</code>: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the <code>-reindex</code> command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (207 GB as of march 2019 - <a href="https://www.blockchain.com/charts/blocks-size" rel="noreferrer">https://www.blockchain.com/charts/blocks-size</a>) for every output being spent.</li>
<li><code>blocks/rev*.dat</code>: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.</li>
</ul>

<p>So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.</p>

CC BY-SA 3.0
2013-05-21T21:17:42.783Z
Ok, thanks.  Does rev*.dat just keep data for rolling back the chainstate/* database?  (I imagine rolling back the blockchain is fairly simply, and just involves pruning off the end blocks and adding the new ones.)
turtlepower
CC BY-SA 3.0
2013-05-21T23:08:14.360Z
Indeed, just the chainstate; the rest is trivial. In particular, it contains the amounts and output scripts that were consumed by a block.
Pieter Wuille
CC BY-SA 3.0
2015-12-07T19:10:06.270Z
Hi. Say I want to implement the entire DB in SQL. Is it possible? If so, what are the pros and cons??
user2277550
CC BY-SA 3.0
2016-10-12T21:29:24.273Z
http://bitcoin.stackexchange.com/questions/41388/mysql-instead-of-leveldb-for-bitcoin-core
Badr Bellaj
CC BY-SA 4.0
2013-05-21T20:31:32.560Z
2019-03-14T16:37:13.530Z
2019-03-14T16:37:13.530Z
Pieter Wuille
<p>I see the block chain is stored according to the block chain format specification.  But I also see there is a database, which is currently a leveldb database.  Why is the block chain stored in two different ways?  Seems redundant.</p>

CC BY-SA 3.0
2013-05-24T03:56:47.647Z
Thanks for asking this question.  From the answer provided I was able to update the Bitcoin wiki: http://en.bitcoin.it/wiki/Data_directory
Stephen Gornick
<blockchain><database>
What is the database for?
turtlepower
# What is the database for?

(Asked by: username_0 on 2013-05-21)

I see the block chain is stored according to the block chain format specification. But I also see there is a database, which is currently a leveldb database. Why is the block chain stored in two different ways? Seems redundant.

**Tags:** blockchain, database

> **Comments:**
> **username_1**: Thanks for asking this question.  From the answer provided I was able to update the Bitcoin wiki: http://en.bitcoin.it/wiki/Data_directory  

---

## 1 answers

### Answer by username_2 on 2013-05-21. Score: 57 | Accepted answer

There are basically four pieces of data that are maintained:

* `blocks/blk*.dat`: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.
* `blocks/index/*`: this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.
* `chainstate/*`: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the `-reindex` command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (207 GB as of march 2019 - <https://www.blockchain.com/charts/blocks-size>) for every output being spent.
* `blocks/rev*.dat`: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.

So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.

> **Comments:**
> **username_0**: Ok, thanks.  Does rev*.dat just keep data for rolling back the chainstate/* database?  (I imagine rolling back the blockchain is fairly simply, and just involves pruning off the end blocks and adding the new ones.)  
> **username_2**: Indeed, just the chainstate; the rest is trivial. In particular, it contains the amounts and output scripts that were consumed by a block.  
> **username_3**: Hi. Say I want to implement the entire DB in SQL. Is it possible? If so, what are the pros and cons??  
> **username_4**: http://bitcoin.stackexchange.com/questions/41388/mysql-instead-of-leveldb-for-bitcoin-core  

---

