The self-hosting argument
Saying that Nuthatch competes with The Graph is a little like saying that graph-node does. Anyone has always been free to run their own graph-node, Postgres and IPFS and index their own subgraph on their own hardware, and nobody has ever called that a rival protocol. It is the protocol's own software, self-hosted. Nuthatch is the same shape with the operational weight taken out: one static binary, an embedded store, no Docker, nothing to rent. A team that runs a nest for the contracts it wrote is not a lost customer of the network, any more than a team running its own graph-node is. Most of them were never going to buy that index from anyone.
The two projects also agree about the thing that matters. The Graph's answer to a centralised data provider is to decentralise who serves you. Nuthatch's answer is that, for the contracts you own, you need not be served at all. Both are ways of not trusting one company's endpoint. Neither is wrong, and they are not exclusive: run your own nest for the protocol you build, and query the network for the fifteen thousand contracts you do not.
And the people. Nuthatch was written by people who spent years inside The Graph's ecosystem and still work there. The front page carries a comparison table with The Graph in it, and it states facts rather than a verdict, because the authors know rather precisely what the network does well.
Where they part ways
Honesty about the seam is the point of this page, so here is what Nuthatch is not. It is not a network. There is no market, no curation, no query fees in the binary, and no dispute process; verification means re-executing deterministic code and getting the same bytes, which is a strong property for one operator and a different property from a decentralised one. It does not speak GraphQL yet; a compatibility layer for subgraph-shaped clients is on the roadmap and not in the release. Contract reads and IPFS documents are pinned and verified rather than fetched freely, so a subgraph that leans on either needs its query surface reviewed rather than assumed. And it does not pretend to serve a hundred thousand subgraphs to strangers from one box. If your application reads from protocols you do not own, across chains you do not run nodes for, the network is the right tool, and Nuthatch will not argue.
What comes next
Two pieces of work point the same way. A hosted nests data service, some of it community-driven, so that a team which does not want to operate a box can still buy a nest through the protocol rather than from a private vendor. And the GraphQL compatibility layer, so a subgraph-shaped client can point at a nest without being rewritten. Neither has a date, because the roadmap promises order rather than dates. Both make a nest a better citizen of the network, not a way around it.
Run your own nest for the contracts you own. Query the network for everything else. Install it, or read the data service.