Question 1

RPC vs indexing: What’s the difference?

Accepted Answer

TL;DR: RPC and indexing are two fundamentally different approaches to accessing blockchain data. RPC endpoints let you query the current state of the blockchain in real time, one request at a time. Indexing extracts, transforms, and stores blockchain data in a searchable database so your application can run complex queries across historical records. RPC is like asking a librarian to find one specific book. Indexing is like building a card catalog for the entire library. Most production applications need both. https://www.youtube.com/watch?v=hmLp8unjClU The Simple Explanation Every blockchain application needs data. A wallet needs account balances. A DeFi dashboard needs token prices and liquidity pool states. An NFT marketplace needs ownership records and transaction history. An analytics platform needs aggregate metrics across thousands of contracts and millions of transactions. The question is how to get that data from the blockchain into your application. RPC endpoints are the blockchain's native interface. When your application sends a JSON-RPC request to a node, it is asking a direct question about the blockchain's current or recent state: what is this wallet's balance right now, what happened in this specific transaction, what does block number 20,000,000 contain. The node looks up the answer and returns it. RPC is immediate, accurate, and straightforward for point lookups. But it has a critical limitation: RPC methods are designed for fetching specific, known data, not for searching or aggregating across the chain. There is no RPC method for "find all transactions from this wallet in the last 30 days" or "show me the top 10 liquidity pools by volume." Indexing fills this gap by building a searchable database on top of raw blockchain data. An indexer reads every block as it is produced, decodes transactions and event logs, transforms the raw data into structured records, and writes those records to a database with proper indexes. Once indexed, your application can query the data using SQL, GraphQL, or any other query language your database supports. Complex filters, aggregations, sorting, joins, and full-text search all become possible. When to Use RPC RPC is the right choice when your application needs to read or write specific, known data in real time. Checking a wallet's current ETH balance is a single "eth_getBalance" call. Submitting a signed transaction to the mempool requires "eth_sendRawTransaction." Reading the return value of a smart contract's view function uses "eth_call." These are all point queries where you know exactly what you want and the RPC method can return it directly. RPC is also the only option for write operations. You cannot submit a transaction through an indexer. Indexers are read-only systems that process data after it has been committed to the chain. Whenever your application needs to send a transaction, approve a token, interact with a smart contract, or broadcast any state-changing operation, it must go through an RPC endpoint. Real-time state verification is another RPC strength. When a DeFi protocol needs to check a user's collateral ratio before executing a liquidation, or when a bridge needs to verify a deposit has been confirmed, it queries the node's current state via RPC. The response reflects the latest canonical block, ensuring the data is as fresh as possible. Where RPC falls short is any query that requires scanning, filtering, or aggregating data across multiple blocks or contracts. "Show me all ERC-20 transfers involving this address" requires iterating through every block and checking every transaction receipt, which is computationally impractical via RPC alone. "What is the total trading volume on Uniswap V3 in the last 24 hours" requires decoding and summing event logs from thousands of blocks across dozens of pool contracts. These are indexing problems. When to Use Indexing Indexing is essential whenever your application needs to search, filter, sort, or aggregate blockchain data. Portfolio trackers that display a user's complete transaction history across multiple tokens and chains depend on indexed data. Analytics dashboards that show trading volume, TVL trends, gas usage patterns, and protocol metrics are built entirely on indexed databases. Block explorers like Etherscan index the entire chain so users can search for any address, transaction, or contract. Historical analysis is another core indexing use case. If a compliance team needs to trace the flow of funds through a series of wallets over six months, that requires querying indexed transaction data with complex joins and filters. If a research firm wants to analyze MEV extraction patterns across a year of Ethereum blocks, it needs a comprehensive index of transactions, traces, and event logs with the computational weight of those queries handled by a database, not a blockchain node. Event-driven architectures also benefit from indexing. Instead of polling RPC endpoints to detect when a specific smart contract event fires, an indexer can continuously process new blocks and push matched events to your application in real time. This is more reliable than WebSocket subscriptions (which can disconnect and miss events) and more efficient than HTTP polling (which wastes requests on empty responses). Using Both Together Most production blockchain applications use RPC and indexing in combination. The user-facing read experience is typically powered by indexed data: portfolio values, transaction histories, analytics dashboards, search results. When the user takes an action (sending a transaction, swapping tokens, minting an NFT), the application switches to RPC to submit the transaction to the network and confirm its inclusion. After the transaction is confirmed, the indexer picks it up from the new block and updates the database, which then reflects in the UI. This architecture separates concerns cleanly. RPC handles real-time writes and point reads. Indexed databases handle complex reads and historical queries. The result is an application that feels fast and responsive to users while supporting sophisticated data access patterns behind the scenes. What is the difference between RPC and indexing? In short, an RPC endpoint answers direct questions about current or specific state, while blockchain indexing pre-processes the chain into a database you can search and aggregate. The table below lays out the practical differences side by side. AspectRPCIndexingAccess patternOne request, one answerSearch, filter, and aggregateData freshnessReal time, latest blockSlight lag behind the chain tipHistorical depthNeeds an archive nodeStored and instantly queryableWrite supportYes, the only way to writeNo, read onlySetup effortLow, call an endpointHigher, build or buy a pipelineBest forLive reads and transactionsAnalytics, history, and search Is an indexer faster than RPC for historical queries? For anything that spans many blocks, yes. Asking an RPC node for a wallet's full history means scanning block by block, while an indexer has already decoded and stored that data, so the same question returns in a single fast query. The deeper the history, the larger the gap: see why querying blockchain data is hard and how real-time and historical data pull in different directions. Query typeBest toolWhyCurrent balance or stateRPCDirect and real timeSubmit a transactionRPCOnly RPC can writeWallet transaction historyIndexerNeeds search across blocksProtocol volume or TVLIndexerNeeds aggregation over timeLive new-block eventsRPC or streamingLow latency push Can you build a blockchain indexer on top of RPC? Yes, and almost every indexer does. An indexer reads the chain through RPC or a streaming feed, decodes each block, and writes structured rows into its own database. The hard parts are handling reorgs, retries, and gaps reliably, which is why many teams use a managed blockchain data streaming pipeline instead of hand-rolling RPC polling loops. Does indexing replace RPC? No. Indexing and RPC are complementary layers of the Web3 infrastructure stack. RPC remains the only way to submit transactions and read fresh state, while indexing powers search, history, and analytics. Production apps route writes and live reads to RPC and route complex reads to an index. Frequently Asked Questions Can you submit transactions through an indexer? No. Indexers are read-only systems that process data after it is committed to the chain. Every transaction submission must go through an RPC endpoint. Why is RPC slow for analytics queries? RPC returns one piece of known data per call and cannot filter or aggregate across the chain. Answering an analytics question with RPC means making thousands of sequential calls and combining the results yourself, which is slow and expensive. How fresh is indexed data compared to RPC? Indexed data usually lags the chain tip by seconds to a few minutes, depending on the indexer. RPC reflects the latest canonical block, so for sub-second freshness you still read directly from a node. Do you need an archive node for indexing? To backfill deep history you need archive data, either from an archive node or a backfill pipeline. See full node vs archive node for the distinction. Is The Graph an indexer or an RPC provider? The Graph is an indexing protocol. Its own indexers read the chain through RPC and expose the processed result as queryable subgraphs. It cannot submit transactions or serve sub-second real-time data on its own. How Quicknode Supports Both Quicknode provides infrastructure for both sides of this equation. The Core API delivers globally distributed, low-latency RPC access across 80+ chains, handling real-time reads and transaction submissions with 99.99% uptime and response times 2.5x faster than competitors. Enhanced API methods reduce the number of individual RPC calls needed for common operations like fetching token balances or NFT collections. Quicknode Streams bridges the gap between RPC and indexing by providing a push-based data pipeline that delivers raw or filtered blockchain data directly to your database, data warehouse, or webhook. Instead of building and maintaining custom RPC polling infrastructure to feed your indexer, you configure a Stream and Quicknode handles data extraction, filtering, delivery, reorg correction, and retry logic. Streams supports both real-time streaming and historical backfills, so you can populate your index from genesis and keep it current with a single tool. For teams that need to build their own indexer, Quicknode publishes a step-by-step guide showing how to create a complete blockchain indexer backed by PostgreSQL using Streams. Further Reading Guide to Efficient RPC Requests - Quicknode Building a Blockchain Indexer with Streams - Quicknode Guide Getting Started with Streams - Quicknode Docs Quicknode Core API

Question 2

How to access historical blockchain data

Accepted Answer

Accessing historical blockchain data requires either an archive node (which stores every state snapshot from genesis) or a data backfilling tool that retrieves and stores past blocks in a queryable database. Standard full nodes only retain the most recent 128 blocks of state data and prune everything older, so querying a wallet's balance from six months ago on a full node will fail. The two main approaches are archive node RPC access for point-in-time state queries and streaming backfills for building comprehensive historical databases.

Question 3

What is blockchain indexing?

Accepted Answer

Blockchain indexing is the process of extracting raw data from a blockchain, transforming it into a structured format, and storing it in a database optimized for fast queries. Blockchains are designed for security and immutability, not for searching. Without indexing, answering even simple questions like "show me all transfers from this wallet" requires scanning every block from genesis, which is impractical at scale. Indexers solve this by creating queryable databases that make onchain data accessible to applications in real time.

Question 4

Why querying blockchain data is hard

Accepted Answer

Blockchains are optimized for security and immutability, not for data retrieval. There are no built-in search functions, no SQL queries, no indexes, and no way to filter or aggregate data across blocks using standard RPC methods. Querying even simple questions like "show all transfers from this wallet" requires scanning millions of blocks sequentially. Add chain reorganizations, varying finality models, encoded data formats, and massive data volumes, and it becomes clear why blockchain data access is a significant engineering challenge.

面向	RPC	索引編製
存取模式	一個請求，一個答案	搜尋、篩選與彙總
資料的新鮮度	即時、最新區塊	與鏈條尖端略有滯後
歷史深度	需要一個存檔節點	已儲存且可立即查詢
寫入支援	是的，寫作的唯一方法是	不，僅限讀取
設定所需的工作量	洛，打個電話給endpoint	Higher，自建或購置管線
最適合	即時讀取與交易	分析、歷史紀錄與搜尋

查詢類型	最佳工具	為什麼
當前餘額或狀態	RPC	直接且即時
提交一筆交易	RPC	只有 RPC 可以寫入
錢包交易紀錄	索引器	需要跨區塊搜尋
協議總量或 TVL	索引器	需要進行時間序列彙總
新區塊即時活動	RPC 或串流	低延遲推送

想掌握最新動態嗎？

開發者工具

文件與指南

RPC 與索引：兩者有何區別？

簡單的解釋

何時該使用 RPC

何時應使用索引

兩者併用

RPC 與索引之間有何區別？

對於歷史查詢而言，索引器是否比 RPC 更快？

能否在 RPC 之上建置一個區塊鏈索引器？

索引會取代 RPC 嗎？

常見問題

能否透過索引器提交交易？

為什麼 RPC 在執行分析查詢時會變慢？

與 RPC 相比，索引資料的即時性有多高？

您需要一個用於建立索引的存檔節點嗎？

The Graph 究竟是索引器還是 RPC 提供者？

Quicknode 是如何同時支援這兩者的

延伸閱讀

立即開始建構