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 如何同时支持这两者

延伸阅读

立即开始构建