Skip to main content

Goldsky

Blockchain indexing for app backends

Talk to our team

What it is

Blockchain indexing for an app backend is turning your contracts’ events into rows in the database your app reads, and keeping those rows in step with the chain; the service that does it is called an indexer.

Wallets, DeFi protocols and fintech apps need it because their screens and APIs read from tables, and reading the chain directly for every screen is slow and can’t sort, filter or join.

Goldsky decodes the events and keeps your tables current, correcting rows when the chain replaces recent blocks, while the API your app calls and the data model behind it stay yours.

You can build it two ways: stream decoded events into your own database with Turbo Pipelines, or index them in a subgraph that Goldsky hosts behind a GraphQL API.

Who it’s for

Wallet apps, DeFi protocols and fintech apps that serve their users from their own backend.

How blockchain indexing keeps an app’s database in sync

The diagram follows one user action from the chain to the screen your app serves from its own tables, and shows who does each step. Your setup may differ.

Goldsky, step 2: TurboDecode the eventContract events turned into typed rows
Blockchains, step 1: User acts onchainA user mints, trades or claims
Your business, step 5: Serve the appYour API reads from your own tables
Goldsky, steps 3–4: TurboSync your databaseRows upserted into your app’s database
  • Goldsky

Ways to index blockchain data for an app backend

Rows from the pipeline go into a database you own, which your API queries and joins with your app’s data; the subgraph keeps the index with Goldsky and serves it over GraphQL.

Usual setupOption 1: Stream to your database
Best for
High event volume, joined with your own tables
Products
Turbo
What you run
The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write
Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives
In your own database or systems
How results reach you
Pushed to you
Option 2: Hosted subgraph
Best for
Moderate traffic, with no database to run
Products
Subgraphs
What you run
Nothing; Goldsky runs indexing, storage and the API
What you write
A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives
Hosted by Goldsky
How results reach you
You query; changes are pushed

Option 1: Index blockchain data for an app backend by streaming to your database

A pipeline decodes your contracts’ events and upserts them into your app’s database as blocks arrive, and corrects the same rows when a reorg replaces a block. Your API reads those tables like any others.

When to stream chain data into your app’s database

Your contracts emit many events, or you want chain data in tables you can join with users, accounts and the rest of your app’s data.

What you’ll need

  • Goldsky Turbo
  • The addresses and ABIs of your contracts
  • A database your app reads
  • Your app’s API or backend service

  1. Record the user’s action on the chain

    A mint, trade or claim happens when the user’s transaction is included in a block.

    Your contract emits an event that describes what happened. For a short time the newest blocks can still be replaced (a reorg), so an event seen once may disappear or change.

  2. Decode the event

    Handled by Goldsky Turbo

    Contract events arrive as encoded bytes, and your app needs typed fields like player, item and amount.

    Each event is decoded with the contract’s ABI into a row with a stable ID, so the same event always maps to the same row. Without that ID, a repeated delivery becomes a duplicate row.

    A Turbo Pipelines SQL transform decodes each log with _gs_log_decode() and your ABI, and carries the dataset’s id through as the row key.

    Decode logs with _gs_log_decode (opens in a new tab)

  3. Sync your app’s database

    Handled by Goldsky Turbo

    Your app reads its own tables, so each decoded event has to land there as it happens.

    Rows are inserted or updated by key, so a delivery that repeats overwrites the same row. A table written with plain inserts collects duplicates after any restart.

    The database sink in Turbo Pipelines creates the table if it doesn’t exist and upserts on the primary_key you set.

    Upsert rows into Postgres (opens in a new tab)

  4. Correct rows after a reorg

    Handled by Goldsky Turbo

    When the chain replaces recent blocks, the events in them can vanish or change, and your tables have to follow.

    Rows from a replaced block have to be deleted or updated. If they aren’t, your app shows items and balances the chain no longer has.

    Goldsky’s Turbo Pipelines passes reorg corrections through as deletes and updates, and keyed database sinks apply them to the same rows.

    How reorgs reach your tables (opens in a new tab)

  5. Serve the app from your tables

    Your screens and API read from the database, which can sort, filter and join in ways the chain can’t.

    Your API queries the tables and combines them with your own data, such as user profiles. Screens that show money can mark the newest rows as pending until they’re a few blocks deep.

What to know about streaming into your app’s database

  • Goldsky runs the pipeline; you run the database and the API on top of it, and design the tables.
  • Rows arrive as blocks do, so nothing in your backend polls the chain.
  • Tables keyed on a primary_key take reorg corrections as updates and deletes, so they follow the chain without code on your side.
  • History can be loaded from your contracts’ first block before the pipeline follows new ones.

Option 2: Index blockchain data for an app backend with a hosted subgraph

You write a schema and mappings for your contracts, or generate them from a contract address, and Goldsky indexes the history and serves it at a GraphQL endpoint your app queries, with webhooks to your backend when records change.

When to use a hosted subgraph

Your app has moderate event and query traffic on EVM chains, and you’d rather query a hosted GraphQL API than run a database for chain data.

What you’ll need

  • Goldsky Subgraphs
  • The addresses of your contracts and the network they run on
  • A code repository for the schema and mappings
  • An HTTPS endpoint on your backend, if you use webhooks

  1. Record the user’s action on the chain

    A mint, trade or claim happens when the user’s transaction is included in a block.

    Your contract emits an event that describes what happened. For a short time the newest blocks can still be replaced (a reorg), so an event seen once may disappear or change.

  2. Define the schema and mappings

    The index has to know which events matter and how to turn each one into records your app can query.

    The schema sets the records (entities) and their fields, and the mappings are the code that creates or updates them from each event. A field left out can’t be queried later without a new version and a fresh index.

  3. Index the events and follow reorgs

    Handled by Goldsky Subgraphs

    Your app needs every past event and each new one, with records that match the chain after a reorg.

    Indexing starts at the block where the contract was deployed, runs every event through the mappings and then keeps up with new blocks. Records from a replaced block have to be rolled back, or the app shows state the chain no longer has.

    Goldsky Subgraphs runs the same mapping code as other subgraph hosts and stores every version of each entity with its block_range, which is how changes from replaced blocks are told apart and rolled back.

    Deploy a subgraph (opens in a new tab)

  4. Serve the index over GraphQL

    Handled by Goldsky Subgraphs

    Your app reads the data by sending queries to an endpoint.

    The endpoint keeps responding while new blocks are indexed. Anyone who finds an open endpoint can query it, so data that isn’t meant to be public needs one that requires a key.

    Subgraphs gives every subgraph and tag its own GraphQL endpoint. You can switch a tag to a private endpoint, which accepts only requests with a project API token in the Authorization header.

    Set up public and private endpoints (opens in a new tab)

  5. Push record changes to your backend

    Handled by Goldsky Subgraphs

    Some features, such as a notification after a mint, react to a change instead of asking for it.

    Each change reaches your server with enough detail to tell a new record from an update or a rollback. Changes can arrive out of order, so your server compares versions instead of trusting arrival order.

    You can attach a webhook to an entity in Subgraphs, and every change arrives as an INSERT, UPDATE or DELETE payload carrying the version’s block_range.

    Set up subgraph webhooks (opens in a new tab)

  6. Serve the app from the index

    Your screens query the index, through one address that survives new versions of the subgraph.

    Point the app at a tag, a stable name you move to a new version once it has caught up. A hard-coded version turns every subgraph update into an app release too.

What to know about a hosted subgraph

  • Goldsky runs indexing, storage and the API, so the data lives in the subgraph, not in your database.
  • The index holds only what your contracts emit; joining it with your own data happens in your app.
  • Indexing and query delay grow as event volume climbs, so contracts with heavy traffic suit a pipeline better.
  • Subgraphs written for other hosts deploy without code changes.

What you control

Your team
  • Serve the app from your tables

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that stream chain data to your systems

Use cases built the same way

Index blockchain data for an app backend with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status