Indexing Co vs Alchemy
Alchemy is the leading Web3 developer platform for RPC, enhanced APIs, and webhooks. Indexing Co is a data pipeline that delivers indexed contract events to your own database in your schema.
Your protocol has a custom staking contract. You need every Staked, Unstaked, and RewardClaimed event stored in your PostgreSQL database, decoded, enriched with a USD value at time of event, and queryable by your analytics team in real time. You open Alchemy's docs. The NFT API, Token API, Wallet API — none of them cover your contract. You look at Subgraphs. You write AssemblyScript mappings, deploy, wait for sync, and end up with a GraphQL endpoint that your analytics team can't connect to their BI tool directly. Now you're thinking about a pipeline.
That's where an RPC platform ends and a data pipeline begins.
Architecture
Alchemy sits at the RPC layer. It provides the connection to blockchain nodes: you send requests, the node responds. On top of raw RPC, Alchemy adds enhanced APIs (NFT API, Token API, Wallet API), webhooks for activity notifications, and Smart Websockets for subscriptions. Their Subgraphs product (via Graph Protocol) handles contract event indexing.
This is the right layer for most Web3 development work. You need to read a wallet balance, check an NFT's metadata, simulate a transaction, or subscribe to transfer events in real time. Alchemy is fast, reliable, and has the broadest set of enhanced APIs in the ecosystem.
The constraint is the same for every API layer: you work within their data model. When you need data shaped for your product, in your schema, in your database, transformed to match your domain, you're working against the grain of an API.
Indexing Co sits above the RPC layer. It reads from blockchain nodes (including Alchemy's), decodes contract events, runs your TypeScript transforms, and writes directly to your PostgreSQL database, BigQuery dataset, or webhook endpoint. Your schema, your destination, your logic.
There's no API to query. The data is in your database. Your analytics team, your BI tools, your ML models all connect to infrastructure you already own.
The two products answer different questions. Alchemy answers "give me this data now." Indexing Co answers "keep that data in my database, always up to date, shaped the way I need it."
Feature Comparison
| Feature | Alchemy | Indexing Co |
|---|---|---|
| Primary function | RPC endpoints + enhanced APIs | Custom blockchain data pipelines |
| Data delivery | API endpoints, webhooks, websockets | Direct to your PostgreSQL, BigQuery, or webhook |
| Schema control | Alchemy-defined (NFT/Token/Wallet API shapes) | You define the schema |
| Custom contract events | Via Subgraphs (AssemblyScript, GraphQL output) | Full raw event indexing with TypeScript transforms |
| Chain support | 50+ (Ethereum, Solana, BNB, Polygon, Arbitrum, Base, Starknet, others) | 100+ chains, all major EVM and non-EVM |
| Block-to-database delivery | API response time | sub-500ms (dedicated infra) |
| Data volume | CU-based rate limits per tier | 1B+ events/day processed |
| Transform language | Not applicable (API layer) | TypeScript |
| Pre-built APIs | NFT, Token, Wallet, Gas, Account Abstraction | Not applicable, pipeline, not API |
| Managed infrastructure | Yes | Yes |
| Pricing model | Free: 30M CUs/month. PAYG: ~$0.45/M CU. Enterprise: custom | Contact for pipeline pricing |
| Customers | OpenSea, Aave, Meta, Adobe, Maker | Data-heavy protocols, analytics teams, fintech |
When to Use Each
- You need RPC access to Ethereum, Solana, or other major chains
- You're using their NFT API, Token API, or Wallet API for standard queries, these are genuinely well-built products
- You need webhooks for wallet activity or transfer events, delivered to your app in real time
- You're building with Account Abstraction and want their Gas Manager and AA SDK
- You want the broadest developer platform in the Web3 ecosystem with strong reliability guarantees
- You need custom smart contract events stored in your own database
- Your schema has to match your product domain, not a pre-built API shape
- You're feeding blockchain data into a data warehouse, BI tool, or ML pipeline that needs direct DB access
- You want TypeScript transforms that run before the data reaches storage, decoding, enriching, filtering at the pipeline layer
- You're processing high event volumes across many chains and need delivery guarantees, not CU-based rate limits
They're Not Mutually Exclusive
Many teams use both. Alchemy handles RPC calls and enhanced API queries within the application. Indexing Co runs alongside as the pipeline that keeps their database current. Alchemy is upstream, it's one of the node providers Indexing Co uses to source raw chain data. The two products occupy different parts of the stack and solve different problems.
If your product works within Alchemy's pre-built API surface, you probably don't need a separate pipeline. If you've hit the edge of what their endpoints cover, a pipeline is the natural next step, not a replacement for Alchemy.