Should You Self-Host a Subgraph?
Self-hosting a subgraph is easy to start but expensive to operate. This guide breaks down the real cost of running Graph Node in production and when a managed provider is the better choice.
Running Graph Node yourself is straightforward, but keeping it running in production can be costly. We provide a breakdown of the associated costs of managing indexing or self-hosting a subgraph.
Graph Node is open-source, well-documented, and easy to spin up. You connect it to PostgreSQL, give it access to an RPC node and IPFS, deploy your subgraph, and start serving GraphQL queries. Any experienced backend engineer can get there in an afternoon.
But the time it takes to spin up isn't the actual cost. The cost mainly comes from maintenance, when a dedicated personnel member needs to own indexing lag, RPC failures, database growth, and version upgrades alongside whatever they were hired to build.
TL;DR
- Spinning up a Graph Node is a one-day task, but operating it in production means monitoring, backups, RPC failover, upgrades, and an on-call owner, and that work does not end.
- The server bill is the smallest line item. Taking up engineering resources is the largest issue, and comparisons often understate the actual complexity and logistics involved.
- Self-hosting pays off with the right team composition or resources.
- Managed hosting pays off when the subgraph matters to your product but operating it does nothing for your product.
- Using a managed provider does not transfer ownership of your data model. You keep the schema, mappings, and indexing logic. The provider runs the machinery underneath.
Why managed hosting?
Subgraphs moved from analytics side projects to load-bearing product infrastructure. Wallets require balances, lending interfaces need positions, and trading front ends read order history from them. When subgraph sync falls behind the chain tip, the users will see stale data on the front end and make decisions off essentially false information.
At the same time, apps are deploying across more networks than before. Each new chain adds its own RPC providers, reorg behaviour, and finality assumptions. A setup that was manageable on one chain becomes a rotation of small, unfamiliar failures on five.
The question here is what are the costs of maintenance relative to what those engineering hours could produce
What running a subgraph in production involves
A few phases are involved from initial deployment to providing a reliable setup.
1. Spinning up the core services
Graph Node needs PostgreSQL for storage, an RPC (remote procedure call) endpoint for blockchain data, and IPFS access to fetch deployment files.
2. Secure and expose the query endpoint
A production endpoint needs TLS, authentication or an API gateway, and rate limiting. A public GraphQL endpoint with no query cost limits is an easy way to have your database taken down by a single expensive nested query.
3. Monitor sync state and uptime
Graph Node can be healthy and still be forty thousand blocks behind. Useful alerting tracks the gap between chain head and indexed head, mapping handler errors, and per-deployment failure state. Process uptime tells you almost nothing.
4. Handling RPC quality
Indexing throughput depends on your RPC provider more than on your own hardware. Providers rate-limit, return incomplete logs, serve stale state during reorgs, and occasionally go down. You need a fallback endpoint and a way to detect bad responses; otherwise, the subgraph indexes incorrect data.
5. Manage database growth
Entity storage grows with history and never shrinks on its own. Indexing writes, and application reads compete for the same PostgreSQL instance. At some point you add read replicas, split query traffic from indexing traffic, or move your heaviest deployment onto its own database.
6. Graph node updates
Graph Node releases change indexing behaviour. Some upgrades require a full resync, which on a mature subgraph can take days. You also need tested backups, because a corrupted database with no restore path means reindexing from genesis.
None of these steps is exotic. Together they are the ordinary maintenance burden of production data infrastructure, carried by a team that in most cases has no dedicated platform engineer.
How to evaluate
| Approach | What you operate | Best suited for | Limitation |
|---|---|---|---|
| Self-hosted Graph Node | Graph Node, PostgreSQL, RPC connections, monitoring, backups, upgrades | Teams with an existing platform function, custom ingestion needs, or compliance boundaries | Ongoing operational load falls on product engineers |
| Managed subgraph provider | Schema, mappings, and indexing logic only | Apps that need reliable subgraph data without running the stack | You depend on the provider's chain coverage, latency, and pricing model |
| Decentralized indexing network | Schema and mappings, plus curation and query fee management | Public, censorship-resistant data access for protocols | Indexer availability and sync times for a given subgraph vary |
Ormi Subgraphs sits in the second category, running managed subgraphs on high-performance infrastructure.
Why engineering time is a tradeoff
Self-hosting looks like the better choice because a monthly server cost is all that is required in the beginning. In reality, the full operating cost includes several lines that gradually appear over time, such as:
- Database storage: grows every week and needs provisioned IOPS to keep indexing throughput acceptable.
- RPC access: an indexing workload consumes far more requests than casual reads, so free tiers stop working early.
- Redundancy: a standby database and a second RPC provider, both paid for and neither used most of the time.
- Monitoring and backups: the tooling itself is cheap, and configuring it correctly for indexing-specific failure modes is not.
- Engineering hours: investigating stalled indexing, chasing bad RPC responses, running upgrades, restoring databases, and explaining query latency regressions.
Engineering resources will be the most costly. Take a backend engineer at $160,000 per annum, which works out to roughly $80 an hour. Four hours a week on indexing infrastructure would cost about $16,000 a year, and four hours a week is an extremely ideal scenario. An incident that leads to a forced resync can consume that budget in a fortnight.
This does not mean self-hosting is automatically the most expensive option in every case. A team that already operates blockchain nodes, runs databases at scale, and staffs an on-call rotation can afford to add Graph Node into systems it maintains anyway. The marginal cost here is small.
For a ten-person startup with two backend engineers, the comparison should be on total operating cost against the features those engineers would otherwise have shipped.
What changes when a managed provider runs it
The value shows up as a difference in what a small team can do before and after.
- Time to production: Before, a self-hosted setup starts as a two-day project and becomes a two-week one once you add backups, alerts, TLS, and a staging environment. After, deployment is the whole task.
- Adding a chain: Before, each new network means evaluating RPC providers, learning its reorg behaviour, and rebuilding monitoring for it. After, you deploy the same subgraph against a network the provider already supports.
- Traffic spikes: Before, a token launch or incentive campaign forces database and query architecture changes under time pressure. After, absorbing the spike is the provider's problem.
- On-call load: Before, indexing failures interrupt whichever engineer is closest to a keyboard. After, they page someone whose job is indexing infrastructure.
- Cost predictability: Before, spend rises with storage, RPC usage, and incident hours, none of which forecast well. After, fixed per-subgraph pricing gives you a cost you can put in a budget.
Hosting does not transfer your data model
You decide which contracts to index, how entities are structured, how events map onto those entities, and how your application queries the result. You still write and version the mappings, and you still update the subgraph when a contract or a product requirement changes. That logic encodes what your product knows, and it stays yours.
The hosted provider runs the databases, chain connections, query layer, and monitoring.
When self-hosting is the right call
Unsupported networks. If your target chain is not covered by any managed provider, the decision is made for you.
Compliance boundaries. Some institutional and regulated deployments require data to stay inside your own network perimeter. A hosted endpoint may not survive that review.
Custom ingestion or a patched Graph Node. If you need to modify indexing behaviour, feed Graph Node from your own pipeline, or wire it into internal systems, a managed platform will not reach far enough.
An existing platform team. Where database operations, monitoring, and on-call rotations already exist, Graph Node joins a workflow instead of creating one.
Indexing is the product. If you sell blockchain data, controlling ingestion, storage, and query execution is your competitive position. Outsourcing it would be strange.
Three questions to help evaluation
Does owning this infrastructure make the product better? If not, then using a hosted provider might be more economically feasible.
Who owns it in production? Have a dedicated person. That person will handle database health, RPC failures, indexing errors, upgrades, and recovery. If you cannot name a dedicated person, the work lands on whoever is available when it breaks, which is the most expensive possible arrangement.
What breaks when the subgraph stops? A stale internal dashboard is an annoyance. Stale positions in a lending protocol or a trading interface cost your users money. The cost of self-hosting scales with the cost of failure.
Running subgraphs on Ormi
Ormi Subgraphs runs production subgraphs on Graph-compatible infrastructure, so your existing schemas, mappings, and development workflow carry over without rewrites.
Teams get sync progress, deployment logs, version management, and private endpoints without building the production stack behind them. Pricing is fixed per subgraph, which keeps the bill predictable as query volume and entity storage grow.
About Ormi
Ormi is the next-generation data layer for Web3, purpose-built for real-time, high-throughput applications like DeFi, gaming, wallets, and on-chain infrastructure. Its hybrid architecture ensures sub-30ms latency and up to 4,000 RPS for live subgraph indexing.
With 99.9% uptime and deployments across ecosystems representing $50B+ in TVL and $100B+ in annual transaction volume, Ormi is trusted to power the most demanding production environments without throttling or delay.