This has been an incredible discussion. I want to bring it down from the philosophical level to the practical reality of how product teams actually make these decisions.
I manage a product at a Web3 sustainability protocol. We are a team of 8. We have limited engineering bandwidth and a roadmap full of user-facing features to ship. Here is how the indexing decision actually played out for us:
The decision matrix we used:
We scored each option across five dimensions:
- Migration effort (engineering hours to switch)
- Ongoing operational cost (monthly spend)
- Performance impact on users (latency, reliability)
- Strategic risk (vendor lock-in, censorship, business continuity)
- Team cognitive load (complexity of managing the solution)
Our scores (1-5, higher is better):
| Criteria | Graph Decentralized | Ormi | Goldsky | Self-hosted |
|---|---|---|---|---|
| Migration effort | 3 | 5 | 2 | 1 |
| Ongoing cost | 2 | 4 | 3 | 4 |
| User performance | 2 | 5 | 4 | 4 |
| Strategic risk | 5 | 2 | 2 | 4 |
| Team cognitive load | 2 | 4 | 3 | 1 |
| Total | 14 | 20 | 14 | 14 |
Ormi won by a significant margin for our specific situation. The subgraph compatibility meant near-zero migration effort. The performance improvement was immediate and user-visible. The operational simplicity meant our team could focus on product features instead of infrastructure.
But Brian’s point about centralization risk haunts me.
We scored Ormi lowest on strategic risk precisely because of the concerns Brian raised. We are a sustainability protocol – our mission is to build long-term, resilient systems. Depending on a centralized startup for our data layer is antithetical to that mission.
Our compromise: we are using Ormi for production today, but we maintain our subgraph deployment on The Graph’s decentralized network as a fallback. If Ormi ever becomes unavailable, we can switch our query endpoint to the decentralized network within minutes. The performance degradation would be noticeable but not catastrophic.
My advice for other product teams:
Do not let the perfect be the enemy of the good. Use the best tool for your current situation, but always have a migration plan. The indexing landscape is changing rapidly, and the right choice today might not be the right choice in six months. Build your architecture so that the indexing provider is a swappable component, not a deeply integrated dependency.