BitcoinDatabase.com

Query the chain · Query with SQL

Query the Bitcoin blockchain with plain SQL

To query the Bitcoin blockchain with SQL, you normally have to run a node, build an indexer, and write your own ETL just to get tables to query. BitcoinDatabase has done that for you. The whole chain since the 2009 genesis block is modeled as clean tables, blocks, transactions, inputs, outputs, addresses, balances, UTXOs, labels and metrics, that you query in plain SQL.

or try it below ↓

REST API · SQL · dashboards · indexed from genesis

Query Console
btc
try:

Hit Run to query the fully-indexed Bitcoin blockchain.

BTC

30-day trend

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Querying the indexed Bitcoin blockchain ...

Join transactions to addresses, aggregate flows, build a custom metric, or slice the rich list by balance band, all in a familiar query language. The same data is also available via REST and dashboards. It is informational on-chain data only, not financial or investment advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

Indexed from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Query with SQL

The chain as tables

Blocks, transactions, inputs, outputs, addresses, UTXOs, labels and metrics are modeled as clean tables you can join and aggregate in plain SQL.

No node, no ETL

Skip running Bitcoin Core, building an indexer and writing pipelines. The chain is already parsed and reconciled, so you start with a query.

Analyst-ready

Use the SQL you already know to trace flows, build custom metrics or slice the rich list, then drill into the exact rows behind any result.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Query blocks, transactions and addresses as tables
  • Join inputs and outputs to trace flows
  • Aggregate UTXOs and balances at scale
  • Build custom on-chain metrics in SQL
  • Skip running a node, indexer or ETL
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Query with SQL

Blocks, transactions, inputs, outputs, addresses, balances, UTXOs, entity labels and precomputed metrics, all from the fully-indexed chain. You write standard SQL to join and aggregate them, with no node or ETL on your side.
A node gives you raw block data you still have to index and model. BitcoinDatabase delivers the chain pre-indexed as queryable SQL tables. It is informational on-chain data only and not investment advice.
The public dataset gives you four raw tables, blocks, transactions, inputs and outputs, and bills per terabyte scanned, so balances and entity labels are aggregations you build and pay for on every run. BitcoinDatabase indexes balances, UTXOs, labels and flows ahead of time, so the same question is a lookup. See the full BigQuery comparison for the tradeoffs.
Yes. Filter the address column against an array of addresses and you get one row per match, whether the list is ten addresses or fifty thousand. That matters because the alternative, one lookup per address, is what turns a reconciliation job into an overnight batch.
Yes. The SQL endpoint returns JSON rows, so pandas.DataFrame on the rows list gives you a frame directly from a requests call, with no database driver to install. Keep satoshi amounts as integers through the query and convert to BTC in the display layer, because a float column will quietly lose precision once you sum tens of thousands of outputs.
There is no separate database connection to set up. SQL runs over the same REST API as everything else: you POST your query to /v1/sql with your bearer key in the Authorization header and read the rows back in the response. Anything that can make an HTTP request can run a query, so there is no driver or client library to install.
You need one thing: your API key, sent as a bearer token on the request. There is no host, port, username or password to manage, because you are not opening a database session. Queries are read-only by design, since the index is a reconciled copy of the chain and nothing in the workload should write to it.
In the API docs, in the SQL access section next to the REST endpoint reference. The schema follows the chain's own structure: blocks, transactions, inputs and outputs as the core tables, with addresses, balances, UTXOs, entity labels and daily metric tables to join against. Anyone who has queried a blockchain dataset before will recognize the shape.
Yes. The docs open with a runnable one, selecting active addresses by day from the daily metrics table, and the examples build from there: an address balance at a past height, the largest transactions in a range, supply grouped by script type, fee rates by block, and exchange inflow over a window. Each is a template to edit rather than a snippet to study.
Raw SQL is available from the Growth plan upward rather than on the entry tier, and a SQL query consumes more credits than a single REST lookup because it does more work. One thing to be straight about: the figures on our pricing page are what we intend to launch with, and BitcoinDatabase is not purchasable yet, so treat them as planned rather than live.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, indexed from the genesis block. Informational on-chain data only, not financial advice.

See pricing

Indexed from genesis · REST · SQL · dashboards · addresses, transactions, UTXOs, metrics