With The Graph’s hosted service officially dead and the decentralized network struggling with performance and cost issues, a new generation of indexing platforms has emerged to fill the vacuum. I have spent the past month evaluating Ormi, Goldsky, and SubQuery for our analytics infrastructure, and I want to share a detailed comparison for anyone else going through this decision.
The Contenders
Ormi: The Speed Demon
Ormi has positioned itself as the direct replacement for The Graph’s hosted service, and the numbers are hard to ignore. Their headline claims: sub-30ms query latency at 4,000 requests per second with full subgraph compatibility.
What I tested:
- Migrated three existing subgraphs (ERC-20 transfers, DEX swaps, lending protocol events)
- Ran load tests over a two-week period
- Compared results against the same subgraphs on The Graph’s decentralized network
Results:
- Average query latency: 18-25ms (vs. 400-600ms on The Graph decentralized)
- p99 latency: 45ms (vs. 1200ms+ on The Graph)
- Uptime over 2 weeks: 99.97%
- Subgraph deployment: identical manifests worked without modification
The Chainstack migration story validates these claims at scale. They moved their entire subgraph infrastructure to Ormi and reported similar performance improvements. For teams that need drop-in replacement with better performance, Ormi is the obvious choice.
Concerns: Ormi is a centralized service. Their pricing model is still evolving. The team is relatively small compared to The Graph Foundation. What happens if they cannot sustain their growth?
Goldsky: The Streaming Pioneer
Goldsky took a fundamentally different approach. Instead of trying to be a faster subgraph host, they rebuilt the data pipeline from scratch around real-time streaming and webhooks.
Key features I evaluated:
- Mirror: Syncs on-chain data directly to your database (PostgreSQL, ClickHouse, etc.)
- Webhooks: Push-based notifications for on-chain events
- Subgraph compatibility: They support subgraphs but clearly want you to use their streaming primitives
What I liked:
- The Mirror product is genuinely innovative. Instead of querying an external API, your application reads from its own database. Latency is essentially zero for reads because the data is already local.
- Webhook-based architectures eliminate polling entirely. Your backend reacts to on-chain events as they happen.
- The data ownership model is better. Your data lives in your infrastructure, not theirs.
What concerned me:
- The learning curve is steeper. You are not just swapping an endpoint; you are rethinking your data architecture.
- The streaming approach works brilliantly for event-driven use cases but is overkill for simple historical queries.
- Pricing can get expensive at high volumes of streamed data.
SubQuery: The Multi-Chain Specialist
SubQuery has been quietly building strong multi-chain support while the Ethereum-centric platforms fight over EVM indexing.
What sets them apart:
- Support for Cosmos, Polkadot, Algorand, NEAR, and other non-EVM ecosystems
- Their own decentralized SubQuery Network with SQT token
- Open-source SDK that lets you run your own indexer node
- Flexible data sources beyond just smart contract events
Where they shine:
- If you are building cross-chain applications or working outside the EVM ecosystem, SubQuery is often the only serious option.
- Their SDK is well-documented and the developer experience is solid.
- The ability to self-host gives you a middle ground between centralized and fully decentralized.
Where they lag:
- For pure EVM performance, they do not match Ormi’s speed claims.
- The SubQuery Network is less mature than The Graph’s decentralized network.
- Ecosystem and community are smaller.
Head-to-Head Comparison
| Feature |
Ormi |
Goldsky |
SubQuery |
| EVM Query Speed |
Sub-30ms |
Varies (local DB reads are fastest) |
50-200ms |
| Subgraph Compat |
Full |
Partial (migrating to streaming) |
Partial |
| Non-EVM Support |
Limited |
Growing |
Excellent |
| Architecture |
Centralized API |
Streaming + Mirroring |
Hybrid (centralized + self-host) |
| Pricing Model |
Usage-based |
Data volume + streaming |
Query-based + SQT token |
| Best For |
Drop-in Graph replacement |
Real-time event-driven apps |
Multi-chain + non-EVM |
My Recommendation
There is no single winner here. The right choice depends on your specific needs:
- Migrating existing subgraphs with minimal effort? Ormi. The subgraph compatibility and performance make it the easiest migration path.
- Building real-time, event-driven applications? Goldsky. The streaming paradigm is genuinely better for these use cases.
- Working across multiple chains including non-EVM? SubQuery. Nothing else comes close for multi-chain coverage.
- Need decentralized indexing? Stay on The Graph. Despite its issues, it is the only truly decentralized option at scale.
The indexing wars are just getting started. Competition is driving innovation, and developers are the beneficiaries. Just make sure you understand the trade-offs before committing to any platform.
Excellent comparison, Mike. As someone building cross-chain infrastructure, I want to add the multi-chain perspective that often gets overlooked in these discussions.
The indexing landscape looks very different when you step outside the Ethereum bubble. Most of the attention goes to Ormi vs. Goldsky for EVM chains, but the real pain point for cross-chain builders is indexing data across heterogeneous networks simultaneously.
The cross-chain indexing problem:
When you are building a bridge or cross-chain protocol, you need to index events from Ethereum, Cosmos, Solana, and whatever new L1 or L2 launches next week. The Graph historically only supported EVM chains well. Ormi is EVM-focused too. Goldsky is expanding but still primarily EVM.
SubQuery is the only platform I have found that genuinely handles multi-chain indexing in a unified framework. I can write indexing logic for Ethereum, Cosmos Hub, and Polkadot parachains using the same SDK and deploy them to the same infrastructure. That consistency matters enormously when you are maintaining dozens of indexers across different chains.
That said, SubQuery has its own challenges:
- Performance on individual EVM chains does not match Ormi. If all you care about is Ethereum, SubQuery is not the best choice.
- Their decentralized network (SubQuery Network with SQT token) is still in early stages. I would not rely on it for production workloads yet.
- Documentation for newer chain integrations can be thin.
My ideal setup would be a hybrid:
- Ormi for critical-path EVM queries where latency matters
- SubQuery for non-EVM chains and cross-chain correlation
- Goldsky Mirror for populating our own analytics database
The industry needs to move toward a world where developers do not have to choose a single indexing platform. Cross-chain interoperability is not just a problem for bridges – it is a problem for data infrastructure too.
Thanks for this detailed breakdown, Mike. I want to share the NFT marketplace perspective because our indexing needs are somewhat unique.
For MetaCanvas, our NFT marketplace, we index:
- Token transfers and ownership history across multiple collections
- Metadata changes for dynamic NFTs
- Marketplace events (listings, sales, bids, cancellations)
- Royalty payment tracking
- Cross-chain NFT bridge events
We were heavily reliant on The Graph’s hosted service for all of this. When the sunset happened, we evaluated all three platforms you mentioned.
Ormi worked great for our standard ERC-721 and ERC-1155 event indexing. The subgraph compatibility meant we could migrate our existing manifest files directly. Query performance improved dramatically, which our users noticed immediately – collection pages load much faster now.
Goldsky was interesting for a different reason. Their webhook system is perfect for sending real-time notifications when NFTs sell, transfer, or have their metadata updated. Instead of polling our subgraph every few seconds to check for new sales, we now get instant webhook callbacks. This completely changed our notification architecture.
SubQuery we passed on because our marketplace is currently EVM-only. If we expand to Solana or Cosmos-based NFT standards, we would revisit.
One thing none of your comparison mentions is indexing IPFS and Arweave metadata alongside on-chain events. This is critical for NFT platforms. We ended up building a custom metadata indexer that runs alongside Ormi’s subgraph indexing. None of the platforms handle off-chain data indexing natively, which is a real gap.
My question for the community: has anyone found a good solution for indexing both on-chain events AND off-chain metadata (IPFS, Arweave, etc.) in a unified pipeline?
Great comparison, Mike. I want to add a dimension that is especially relevant for L2 builders: how do these platforms handle the unique challenges of indexing rollup chains?
L2s introduce several complications for indexers that do not exist on L1:
1. Finality semantics. On optimistic rollups like Arbitrum and Optimism, there is a difference between “soft finality” (sequencer confirmed) and “hard finality” (fraud proof window passed). Your indexer needs to understand this distinction, or you risk serving data that could theoretically be reverted.
2. L1-to-L2 message indexing. Many dApps need to track cross-layer messages – deposits from L1 to L2, withdrawal proofs, etc. Indexing these requires reading from both layers simultaneously.
3. Chain reorgs on L2. Sequencer-level reorgs are more common on L2s than L1. Your indexer needs to handle block reorganizations gracefully without corrupting your indexed state.
4. New L2 chain support cadence. With new rollups launching almost weekly (Base, Blast, Scroll, Linea, zkSync Era, etc.), the ability of an indexing platform to support new chains quickly matters enormously.
From my experience:
- Ormi handles established L2s well (Arbitrum, Optimism, Base) but can be slow to add brand-new chains.
- Goldsky has been faster at adding L2 support, possibly because their streaming architecture makes it easier to add new data sources.
- SubQuery supports some L2s but lags behind on the newest EVM rollups.
- The Graph decentralized network has generally been the slowest to add L2 support because it requires indexer node software updates and migration of indexer operators.
For L2-focused teams, I would recommend evaluating each platform specifically against the chains you need today and the chains you anticipate needing in six months. The indexing platform that cannot keep up with the L2 proliferation will become a bottleneck for your multi-chain strategy.
This is a fantastic comparison from the engineering side, Mike. I want to add the often-overlooked design and developer experience perspective.
As a product designer working on DeFi interfaces, the indexing platform choice directly impacts the user experience I can deliver:
Loading states and perceived performance. The difference between 25ms (Ormi) and 500ms (The Graph decentralized) is not just a number – it is the difference between a page that feels instant and one that needs a loading spinner. Users do not know or care about indexing infrastructure, but they absolutely notice when a dashboard feels sluggish. We ran A/B tests on our protocol’s interface and found that query latency improvements correlated directly with user retention. Faster data loading meant users explored more pages and performed more transactions.
Real-time vs. polling UX. Goldsky’s webhook and streaming approach enables a fundamentally better UX pattern. Instead of showing stale data and forcing users to refresh, we can push updates in real-time. The transaction confirmation experience becomes much smoother when the UI updates the moment an on-chain event is indexed, rather than waiting for the next polling cycle.
Error handling and fallback design. With the decentralized Graph network, I had to design much more robust error states because query failures were more common. Timeout screens, retry mechanisms, fallback data sources – all of this adds design complexity. With Ormi’s more reliable responses, the error handling is simpler and the experience more consistent.
Developer experience matters too. I have watched our engineering team struggle with The Graph’s curation and staking mechanics. The cognitive overhead of managing GRT tokens, understanding indexer selection, and debugging gateway routing issues takes time away from building features. Ormi’s simpler deployment model (deploy subgraph, get endpoint, done) frees up engineering time that translates directly to faster product iteration.
My takeaway: when choosing an indexing platform, do not just look at the technical benchmarks. Think about how the choice impacts the end-user experience and your team’s ability to iterate quickly.