Back to Blog
StreamingFast

Serve Your Substreams Data Over GraphQL: No API Server Required

TL;DR: Hosted Sinks can now expose a read-only GraphQL API and console over the database your sink writes into. It is powered by Hasura, it tracks your tables and views automatically, and you turn it on with a single checkbox, during sink creation or at any time afterward. For teams growing out of a Subgraph and used to querying data with GraphQL, it removes the last piece of friction in taking the next step to Substreams.

What shipped

The GraphQL layer is a new option on StreamingFast Hosted Sinks. When enabled, it deploys alongside your sink and serves a GraphQL API over the same database the sink writes into. You control the database, StreamingFast writes to it, Hasura provides the read layer:

  • Automatic schema. Hasura tracks every table and view in the sink's target schema and generates GraphQL query fields for each one. As your sink creates new tables, the layer picks them up. Views you add yourself are tracked the same way.
  • Read-only by design. Every request runs with a role that has SELECT and nothing else. No insert, update, delete, or mutation fields are ever generated. The sink stays the only writer to your database.
  • A browser console. Explore the schema, build and run queries, and save any query as a REST endpoint under /api/rest. The console signs in with your existing portal session, with no separate login.
  • Postgres and ClickHouse. Both hosted sink database types are supported.
  • Add or remove anytime. It is a separate deployment. Toggling it on or off never touches the pipeline; the sink keeps writing exactly as before.

Requests authenticate with one of your organization's API keys from The Graph Market, passed in an X-Api-Key header.

curl https://<your-sink-endpoint>/v1/graphql \
  -H "X-Api-Key: <your-api-key>" \
  -d '{"query":"{ __typename }"}'

Full guide: Serve your data over GraphQL.

A natural next step from Subgraphs

Subgraphs and Substreams are complementary tools in the same ecosystem. This blog post from The Graph covers how to think about each of them, as well as when to migrate from one to the next. The move is a progression, not a competition, and it does not mean starting over. You reach for Substreams when your usage outgrows what a Subgraph was built for:

  • Forget about multi-day sync times. Substreams parallelizes backfills across CPU cores instead of processing block by block, cutting reprocessing time after every change to your mapping logic.
  • Handle high-throughput chains and heavy server-side transformations.
  • Store data in more than one place. Sink to Postgres, ClickHouse, files, or a stream, not just a single GraphQL endpoint.
  • Access to account-level state tracking and other patterns a linear Subgraph handles poorly.

You stay inside The Graph ecosystem the whole way. Your Subgraph investment carries forward: substreams-convert and the agent skills do most of the port for you, so it is assisted work rather than a manual rewrite. And now, with the GraphQL layer, the query surface on the other side can look familiar too: the same protocol, a browsable console, and REST endpoints.

Note: Hosted Sink GraphQL requests are authenticated with an API key from The Graph Market. If you have only ever used a Subgraph query key before, this is a new key you create via an account on The Graph Market portal; it is not the same credential.

Who this is for

  • Teams scaling a Subgraph that need faster reprocessing, higher throughput, or output beyond GraphQL, without leaving The Graph ecosystem or re-tooling their read layer.
  • Developers who think in GraphQL and want to keep that query surface after moving indexing to Substreams.
  • Anyone who wants to read their indexed data over HTTP without standing up and operating an API server, wiring auth, or keeping a schema in sync with a moving database.

Why the upgrade path is shorter now

The GraphQL layer is the next piece of a larger push to cut the time and knowledge required to move to Substreams:

  • Agentic coding skills. The open-source Substreams agent skills (repo) give a coding agent deep Substreams expertise: scaffolding manifests, writing Rust modules, defining protobufs, building SQL sinks, testing, and converting an existing Subgraph into a Substreams module graph.
  • Hosted Sink service. StreamingFast runs the sink for you. You supply the database; the managed infrastructure handles the sink process, deployment, cursor management, and reorg handling.
  • Hosted GraphQL layer. Now the read side is managed too.

Put together: an agent helps you convert the indexing logic, a Hosted Sink runs it against your database, and a hosted GraphQL API serves it back to your application. Less to build, less to learn, and less to operate than wiring each piece yourself.

Get started

  1. Open the New Sink wizard on The Graph Market.
  2. Configure your Substreams package and database.
    • Haven't written your Substreams package yet? Use the Substreams agent skills to handle that work for you with simple prompting, including converting an existing Subgraph.
  3. At the GraphQL API step, select Expose a GraphQL API over this database.
  4. Deploy. Once the layer reports Deployed, grab the endpoint and console link from the sink's GraphQL panel.

Already running a sink? Open its detail page, click Edit, go to the GraphQL tab, and enable it there.

FAQ

Who hosts the database — StreamingFast or me?

You do. A Hosted Sink writes into a Postgres or ClickHouse database that you own and control (your own instance, or a managed one like Supabase, Neon, or ClickHouse Cloud). StreamingFast never hosts your database. What StreamingFast hosts is the sink process that writes into it, and now, optionally, the GraphQL layer that reads from it. The GraphQL layer is Hasura running as a managed read layer on top of your database, not a database StreamingFast provides.

Does the GraphQL layer let clients write to my database?

No. Every request runs with a database role that has SELECT and nothing else. No insert, update, delete, or mutation fields are generated, and the sink stays the only writer to your database.

Which databases are supported?

Both Hosted Sink database types: Postgres and ClickHouse.

How do requests authenticate?

With one of your organization's API keys from The Graph Market, passed in an X-Api-Key header. A Subgraph query key is a different credential and does not work here; you create a new key from your account's view in The Graph Market dashboard.

Can I add the GraphQL layer to a sink that is already running?

Yes. Open the sink's detail page, click Edit, go to the GraphQL tab, and enable it. It deploys as a separate service, so nothing about the running pipeline changes.

Does enabling it change how the sink runs?

No. The GraphQL layer is a separate deployment that reads from the same database. Toggling it on or off never touches the sink pipeline.

What happens to tables the sink creates later?

Hasura tracks them automatically and generates query fields for each one. Views you add yourself are tracked the same way.

Where do I run queries and get the schema?

From the browser console linked in the sink's GraphQL panel. It signs in with your existing portal session, lets you explore the schema and build queries, and can save any query as a REST endpoint under /api/rest.