How to Query the Bitcoin Blockchain: API vs SQL vs Running a Node

How to query the Bitcoin blockchain without losing a weekend to indexing

How you query the Bitcoin blockchain depends entirely on the question you are asking. "What is the balance of this address?" and "what was the median fee in block 800,000?" and "how much BTC moved to exchanges last week?" all touch the same chain, but they need very different machinery underneath. There are three honest ways to get answers: call a REST API, run SQL against an indexed copy of the chain, or operate your own full node. This guide walks through all three so you can match the tool to the job.

One thing to settle up front: everything below is about reading public, on-chain data for information and analytics. None of it is financial or investment advice. The Bitcoin ledger has been public since the genesis block in January 2009, and every transaction since is verifiable by anyone who looks.

Option 1: A REST API for direct lookups

If you want a specific fact, an address balance, a transaction's confirmations, the details of a block, a REST API is the fastest path. You make one HTTPS call and get back clean JSON. There is no chain to download, no index to maintain, and no server to keep online at 3am.

# look up an address balance in one call
curl https://api.bitcoindatabase.com/v1/address/bc1q...xyz \
  -H "Authorization: Bearer $KEY"

{
  "address": "bc1q...xyz",
  "balance_btc": 12.48310000,
  "tx_count": 184,
  "utxo_count": 6,
  "first_seen": "2019-03-11T08:21:44Z"
}

REST shines for application back-ends: wallets checking a balance, explorers rendering a transaction page, or a webhook that fires when an address receives funds. It is request-and-response, so it is excellent for one record at a time and less suited to sweeping aggregate questions across millions of rows.

Option 2: SQL for analytics across the whole chain

When the question is aggregate ("sum", "count", "group by date", "top 100 addresses"), SQL is the natural language. With the chain decoded into relational tables, blocks, transactions, inputs, outputs and addresses, you can express analytics that would be painful to assemble from individual API calls.

-- the 10 largest balances (a simple rich-list query)
SELECT address, balance_btc
FROM addresses
ORDER BY balance_btc DESC
LIMIT 10;

-- daily transaction count for the last 30 days
SELECT date(b.time) AS day, count(*) AS txs
FROM transactions t
JOIN blocks b ON b.height = t.block_height
WHERE b.time >= now() - interval '30 days'
GROUP BY day
ORDER BY day;

The catch with do-it-yourself SQL is the indexing pipeline. Turning raw block data into clean, queryable tables means handling every script type, reorgs, coinbase outputs, and the sheer volume of a chain that is hundreds of gigabytes and growing. A hosted SQL surface removes that burden: the indexing is already done, kept current as new blocks confirm, and you simply write queries.

Option 3: Running your own full node

A full node, Bitcoin Core being the reference implementation, is the gold standard for trust. It validates every rule independently and gives you a personal source of truth via its JSON-RPC interface. If you are running a wallet that must verify its own transactions, or you simply want maximum sovereignty, a node is the right call.

What a bare node is not good at is analytics. By default it does not maintain an address index, so "the balance of an arbitrary address" is not a question it can answer quickly without extra indexing layers. Initial block download takes hours to days, and you are responsible for storage, bandwidth, upgrades and uptime. Many teams run a node for validation and reach for an API or SQL layer for everything analytical.

Which one should you pick?

Reach for the REST API when

You need specific records inside an application, balances, transactions, confirmations, block details, and you want zero infrastructure to manage. It is the shortest path from idea to working feature.

Reach for SQL when

You are doing research or analytics: cohort analysis, time series, rich lists, flow studies, anything that aggregates across the whole chain. SQL lets you ask open-ended questions without writing a custom aggregation service.

Run your own node when

Independent validation and self-custody are the point, and you accept the operational cost. Many production stacks combine a node for trust with indexed REST and SQL for speed.

A note on confirmations and finality

Whichever route you take, remember that recent data is provisional. A transaction with zero confirmations sits in the mempool and may never confirm. One confirmation means it is in a block; deeper confirmations make a reorg progressively less likely. Good tooling exposes the confirmation count so your application can decide how many it requires before treating a payment as settled.

Get started

BitcoinDatabase gives you all three surfaces over one fully-indexed copy of the chain: a REST API at api.bitcoindatabase.com for direct lookups, SQL for analytics, and dashboards for a quick visual read. You can try a live query right now in the Query Console without writing a line of integration code, then drop the same call into your app when you are ready. Pick whichever surface fits the question in front of you.