How to Download Bitcoin Blockchain Data: Datasets, CSV and SQL

Anyone who has tried to get Bitcoin data for a paper, a model or a product hits the same wall. The chain is public, so the data feels like it should be a download link. Then you discover that the raw format is a stack of binary block files designed for a node to validate, not for you to run a query against. Here is what each route actually involves.

How do I download the Bitcoin blockchain?

Install Bitcoin Core, let it sync, and it will download and validate every block from the 2009 genesis block forward into files under your data directory. As of mid-2026 a full archival copy runs well past 600 GB and keeps growing by roughly 5 to 7 GB a month. Initial block download typically takes anywhere from several hours on a fast NVMe drive and connection to a couple of days on ordinary hardware, because the bottleneck is validating signatures, not bandwidth. Pruned mode keeps a fixed amount of recent block data instead, which is fine for running a wallet but useless if you need history.

Sizes and timings are typical for mid-2026 and vary with hardware and connection.

Where can I get a Bitcoin dataset in CSV?

Search results for a Bitcoin dataset in CSV are dominated by price history files, which are fine if all you need is a daily close, and useless if your question involves transactions. The on-chain datasets that do exist are often a snapshot someone exported years ago, missing address labels and never refreshed. If you want current data with transactions, inputs, outputs and address balances, you are better off querying an indexed copy of the chain and exporting exactly the rows your analysis needs. A scoped export beats a 600 GB download you have to index anyway, and a Bitcoin blockchain dataset you can filter by block range or address set is usually a few hundred megabytes rather than a few hundred gigabytes.

How big is the Bitcoin blockchain?

An archival Bitcoin Core node stores over 600 GB as of mid-2026, growing at roughly 5 to 7 GB per month because blocks arrive about every 10 minutes with a 4 million weight unit limit. That is only the raw blocks. Once you build the address and UTXO indexes needed to answer questions like what is this address balance, expect the working footprint to be a meaningful multiple of the raw size, which is why teams that go this route usually end up running it on cloud storage and then watching what that storage quietly costs them every month.

Do I need a full node to analyze Bitcoin data?

Only if you need to independently validate consensus rules, which most research does not. A node validates; an index answers questions. Running your own node gives you trustless verification and no dependency on anyone else, at the cost of hardware, sync time and maintenance. If your project is measuring exchange flows, studying UTXO age, or building a dashboard, you need the index far more than the validation, and you can always spot-check a handful of results against a public explorer. There is more on this tradeoff in accessing a Bitcoin node without running one.

What data is actually in the Bitcoin blockchain?

Blocks with headers (height, hash, timestamp, difficulty target, nonce), and inside them transactions, each with inputs referencing earlier outputs and outputs carrying a value in satoshis and a locking script. Addresses are derived from those scripts, not stored as a field, and balances are not stored anywhere at all: an address balance is the sum of its unspent outputs, which you can only compute if you have indexed the whole UTXO set. That single fact is why raw block files are not a dataset, and why every practical workflow starts with an index. If UTXOs are new to you, start with what is a UTXO.

Can I get historical Bitcoin data going back to 2009?

Yes, and this is the part public datasets most often get wrong. The chain has recorded every transaction since the genesis block on 3 January 2009, so complete history exists by definition; the question is whether your source indexed all of it or started from a convenient recent height. Early blocks are small and sparse, which makes them cheap to include, so there is no good reason for a dataset to begin in 2015. Check the earliest block height in whatever source you pick before you build on it.

How do you keep a Bitcoin research dataset current?

New blocks arrive about every 10 minutes, so any static export starts drifting immediately. If you run your own stack, you need an ingest process plus reorg handling, because the tip can be reorganized and rows you already wrote may need to be reversed. Most one-off research pipelines skip reorg handling and quietly accumulate a small number of wrong rows. Querying a maintained index moves that problem off your plate, which is usually the real argument for it, more than the storage saving.

The practical setup

BitcoinDatabase indexes every block since 2009 into a normalized schema: blocks, transactions, inputs, outputs, addresses, UTXOs, entity labels and historical market data, queryable over REST for applications, SQL for analysts and dashboards for everyone else, with CSV export on the rows a query returns. You filter to the block range, address set or script type you care about and take the result, without syncing a node or writing an indexer. To see the query patterns first, read how to query the Bitcoin blockchain, or start from the Bitcoin historical data API. Informational on-chain data only, not investment advice.