The Graph Hosted Service Is Gone: What Now for dApp Developers Who Relied on Free Indexing?

defi_diana · February 13, 2026, 6:45am

The day many of us feared has finally arrived. The Graph’s hosted service – the one that let thousands of developers query on-chain data for free – is fully deprecated. No more free subgraphs. No more “just deploy and go.” If you built your dApp on The Graph’s hosted service (and let’s be honest, most of us did at some point), you are now staring down a migration that nobody asked for.

A Brief History of What We Lost

When The Graph launched its hosted service, it was a game-changer. You could write a subgraph manifest, define your schema, deploy it, and within minutes you had a GraphQL endpoint serving indexed blockchain data. For free. No tokens, no staking, no curation signals – just clean, queryable data. It powered thousands of dApps, dashboards, and analytics tools across Ethereum, Polygon, Arbitrum, and dozens of other chains.

The hosted service was the gateway drug to Web3 data infrastructure. Teams building DeFi dashboards, NFT marketplaces, DAO governance interfaces, and on-chain analytics all leaned on it heavily. I personally had four production subgraphs running on the hosted service that powered critical features in our yield optimization platform.

The Decentralized Network: Great in Theory, Painful in Practice

The Graph’s decentralized network is the intended replacement, but let’s talk about what that actually means for developers:

1. You now need GRT tokens. Every query costs GRT. You need to acquire tokens, manage a billing wallet, and monitor your spending. For a small dApp team, this is a non-trivial operational burden.

2. Curation signals matter. Your subgraph needs indexers to pick it up, which means you need curators to signal on it with GRT. If your subgraph is niche (and most are), good luck attracting indexers without significant curation.

3. Query latency increased. The decentralized network routes queries through a gateway, adds token verification, and distributes across indexers. In my testing, average query times went from around 200ms on the hosted service to 500-800ms on the decentralized network. For a real-time DeFi dashboard, that is brutal.

4. Cost is real. We ran the numbers for our protocol. Migrating our four subgraphs to the decentralized network would cost us approximately $400-600 per month in GRT at current prices. That’s not catastrophic, but it’s $400-600 we were not spending before, with arguably worse performance.

The Migration Options

So what are developers actually doing? From conversations with other builders, I see a few patterns emerging:

Bite the bullet and migrate to The Graph’s decentralized network. This is the “official” path, and it makes sense if you believe in decentralized indexing long-term.
Switch to Ormi. They claim sub-30ms queries at 4,000 RPS with full subgraph compatibility. Chainstack already migrated to them. The performance claims are impressive if they hold up.
Move to Goldsky. They have pivoted hard toward real-time streaming and webhooks, which is a fundamentally different paradigm from batch indexing.
Try SubQuery. Especially if you need non-EVM chain support. They have been quietly building strong multi-chain capabilities.
Roll your own indexer. Some larger teams are just writing custom indexing pipelines with tools like Ponder or directly against archive nodes.

What I Am Actually Doing

I am in the process of migrating two of our subgraphs to Ormi and experimenting with Goldsky’s streaming approach for our real-time price feeds. The remaining two subgraphs are lower priority, so I am evaluating whether to move them to the decentralized Graph network or rewrite them entirely.

The honest truth is that The Graph’s hosted service shutdown is forcing the entire ecosystem to grow up. Free infrastructure was never sustainable, and we all knew this day was coming. But the timing – during a period when many teams are already stretched thin – feels particularly painful.

Questions for the Community

Has anyone completed a full migration from the hosted service to a centralized alternative? What was your experience?
For teams that moved to the decentralized Graph network, what are your actual monthly costs?
Is anyone successfully running Ormi in production? Do the performance claims hold up under real load?

I am genuinely curious what paths other builders are taking. This feels like one of those inflection points where the decisions we make now will shape Web3 data infrastructure for years to come.

backend_bob · February 13, 2026, 6:46am

Great breakdown, Diana. I went through this exact migration pain last quarter and want to share what I learned the hard way.

We had six subgraphs on the hosted service powering our infrastructure monitoring dashboard. When the sunset was announced, I initially tried migrating everything to the decentralized network because it felt like the “right” thing to do. That lasted about three weeks before we pulled the plug.

The deal-breaker for us was not cost – it was reliability. Our dashboard needs to serve data to clients with SLAs. When a query intermittently takes 800ms or times out entirely because an indexer is having a bad day, that is a production incident for us. In traditional backend engineering, you would never accept that kind of variance from your database layer.

We ended up going with Ormi for our critical-path subgraphs. The migration was surprisingly smooth because they support the same subgraph manifest format. I literally pointed our deployment at their endpoint, re-deployed, and the queries worked. The performance difference was night and day – our p95 latency dropped from around 600ms to under 40ms. At 4,000 RPS, it handles our peak load without breaking a sweat.

That said, I want to be honest about the trade-off: we gave up decentralization for reliability. Ormi is a centralized service. If they go down, we go down. If they raise prices, we pay or migrate again. In traditional infrastructure, we deal with this all the time (hello, AWS), but it does feel like we are backsliding on the Web3 ethos.

My recommendation for teams evaluating options:

If you need production-grade SLAs: look at Ormi or Goldsky
If you have budget and believe in decentralized indexing: stay on The Graph network
If you are a small team with limited queries: the decentralized network might actually be affordable
If you need non-EVM chains: SubQuery is worth a serious look

The hosted service sunset is painful, but honestly, it is also making us think more carefully about our data infrastructure stack. That is probably a good thing long-term.

startup_steve · February 13, 2026, 6:46am

This hits close to home. We are a pre-seed Web3 startup and the hosted service sunset nearly killed our product roadmap.

Here is the thing nobody talks about: for early-stage startups, free indexing was not just convenient – it was existential. When you are bootstrapping with limited runway, every dollar matters. The difference between $0/month for data indexing and $400-600/month is the difference between affording another month of development or not.

We did the math for our use case. The decentralized Graph network would cost us roughly $300/month at our current query volume. That is manageable but not trivial when your total monthly burn is under $5K. More importantly, the integration complexity would eat up engineering time we do not have.

We ended up going a completely different route: we rolled our own lightweight indexer using Ponder. It took about two weeks of engineering effort, but now we have a custom indexing pipeline that:

Costs us only the price of a small VPS (~$20/month)
Indexes exactly the events we need (no wasted computation)
Gives us sub-10ms query times since the data is local
Is fully under our control

The downside? We lost the convenience of The Graph’s ecosystem. No shared subgraphs, no community of indexers, and we are responsible for our own uptime. But for an early-stage startup, the cost savings and performance gains were worth it.

My advice to other founders in the same boat: do not assume you need a full-featured indexing platform. Look at your actual data needs. If you are querying a handful of smart contracts, a custom solution might be simpler and cheaper than any of the alternatives being discussed here.

That said, if you are scaling beyond a few thousand queries per second, the managed solutions (Ormi, Goldsky, etc.) start to make a lot more economic sense than rolling your own.

blockchain_brian · February 13, 2026, 6:46am

I want to push back on some of the negativity here, not because the migration pain is not real, but because I think we are losing sight of why decentralized indexing matters.

Diana, you mentioned the cost and latency increases. Those are valid concerns. But consider what the hosted service actually was: a single company running centralized infrastructure, subsidized by VC money, with no long-term sustainability model. We all knew it was not going to last forever. The question was always “when,” not “if.”

The decentralized Graph network is building something fundamentally different: a permissionless data layer for Web3. Nobody can censor your subgraph. Nobody can cut off your access. Nobody can change the terms of service on you overnight (looking at you, every centralized API provider ever).

Let me address the specific complaints:

On cost: Yes, GRT tokenomics add cost. But how much do you pay for your RPC provider? Your cloud hosting? Your database? We have normalized paying for infrastructure everywhere except data indexing, and that is largely because The Graph distorted the market with free subsidies.

On latency: The decentralized network is getting faster. Query response times have improved significantly over the past year. Are they at sub-30ms like Ormi? No. But 300-400ms is getting more typical now, and for most use cases, that is perfectly acceptable.

On complexity: The curation and staking mechanics are being simplified. The Graph Foundation is actively working on reducing the friction for developers.

Here is my concern with everyone rushing to centralized alternatives: you are rebuilding the same vendor lock-in that Web3 was supposed to eliminate. Ormi could raise prices tomorrow. Goldsky could pivot again. SubQuery could get acquired. When you depend on a centralized service for your data layer, you are not really building a decentralized application.

I am not saying decentralized indexing is perfect today. But I am saying the trade-off is worth the investment for teams that genuinely care about the decentralization properties of their stack.

ethereum_emma · February 13, 2026, 6:46am

I appreciate both sides of this debate. As someone who came into Web3 relatively recently, the hosted service sunset was my first experience with a major infrastructure rug pull in this space.

When I first started building DeFi frontends, The Graph’s hosted service was one of the first things I learned. Every tutorial, every bootcamp, every “build your first dApp” guide pointed to it. “Just deploy a subgraph and query it with GraphQL” – simple, elegant, free. It was honestly one of the best developer experiences in all of Web3.

Then suddenly it was gone, and I felt a bit betrayed. Not by The Graph specifically, but by the ecosystem that built so much educational material around something that was always going to be temporary.

Here is what I ended up doing for our protocol’s frontend:

Migrated our main subgraph to the decentralized network. It handles about 500 queries per minute, and the cost works out to roughly $50/month in GRT. The latency is noticeable but acceptable for our dashboard.
Moved our real-time price feed to a direct WebSocket connection instead of polling a subgraph. This was actually an improvement – we should have done this ages ago.
Started experimenting with Goldsky’s Mirror product for our analytics views. The streaming approach is actually really compelling for keeping a PostgreSQL database in sync with on-chain state.

The lesson I took from all this: do not put all your eggs in one infrastructure basket. Use different tools for different needs. Real-time data does not need a subgraph. Historical queries might. Aggregated analytics might need a completely different pipeline.

Brian, I hear you on the decentralization argument, and philosophically I agree. But when I have users complaining that the dashboard is slow, my job is to fix the user experience, not to defend an ideology. I think the pragmatic middle ground is to use decentralized infrastructure where it matters most (like core protocol interactions) and centralized services where performance is critical.