Turbo vs Mirror: which Goldsky pipeline should you use?

Use Turbo. Goldsky retired Mirror on 2026-08-19. Turbo Pipelines replaced Mirror as Goldsky's pipeline product. About 95% of Mirror pipelines map onto Turbo with no feature loss, according to the Mirror to Turbo migration guide (opens in a new tab).

What Mirror was

Mirror was Goldsky's original pipeline engine. It streamed onchain data into a sink you control, such as Postgres or Kafka, using a Flink-based SQL transform layer. Existing Mirror pipelines keep running. Goldsky's Which product do I need? (opens in a new tab) page lists Mirror as legacy.

What Turbo is

Turbo (opens in a new tab) is Goldsky's current pipeline engine. It streams raw or transformed onchain data into infrastructure you control: Postgres, ClickHouse, Kafka, S3, webhooks, and more. Pipeline logic runs through SQL or TypeScript transforms.

Turbo adds several things Mirror did not have:

• Solana, Bitcoin, Stellar, and NEAR sources. Goldsky dropped these chains from Mirror. They run on Turbo only now.
• Faster startups. Turbo pipelines start in under 5 seconds, with inter-batch parallelism.
• Live data inspection. The goldsky turbo inspect command shows data flowing through a live pipeline with no performance penalty.
• TypeScript transforms and dynamic tables. Mirror does not support either, as the Turbo quickstart (opens in a new tab) shows.
• Infinite address filters and faster ABI/IDL decoding.
• A DataFusion SQL engine instead of Flink. Goldsky ports Mirror's _gs_* UDFs to Turbo, so most Mirror SQL carries over as-is.

Turbo does not yet cover every Mirror feature. Stay on Mirror if a pipeline depends on subgraph entity sources. Also stay on Mirror for an Elasticsearch, Timescale, DynamoDB, or Snowflake sink. The same holds for Mirror's payload_columns handler option.

What makes Turbo faster: Streamling

Turbo runs on Streamling, a data processing runtime that Goldsky built in Rust and open-sourced in June 2026. Streamling uses Apache Arrow for data in memory and Apache DataFusion for SQL. Mirror ran on Apache Flink. Goldsky wrote Streamling to replace that Flink system.

Goldsky measured these results when it moved its pipelines from Flink to Streamling:

• Over 30x less compute. In a benchmarked Kafka-to-ClickHouse production workload, average CPU use fell from more than 10 cores on Flink to 0.3 cores.
• Over 20x faster startup. The time from a pipeline change to data in the destination fell from more than two minutes on Flink to under 5 seconds.

Three design choices produce these results:

• No state inside the pipeline. Streamling does not support stateful SQL, such as streaming joins. State lives in external databases. A pipeline only has to reload its source position when it restarts.
• Restarts in seconds. If a node fails, the pipeline starts again on a new node in a few seconds and replays the gap. Flink-style standby replicas are not necessary.
• Arrow from end to end. Data moves between pipeline steps as Arrow record batches, often with no copy. Plugins in Rust or WASM work on the same batches.

The same design speeds up historical backfills. A Turbo pipeline reads history from Goldsky's ClickHouse data lake as native Arrow, then switches to the real-time stream at the chain tip. On Base traces, one of Goldsky's densest datasets, this path reads about 600,000 rows per second. The earlier path, Avro messages through Kafka, read about 50,000 rows per second. Both numbers come from the smallest pipeline size. Details are in How we made historical blockchain data backfills 12x faster.

Streamling is open source at github.com/goldsky-io/streamling (opens in a new tab). For the full design, read Open-sourcing Streamling: the data processing runtime for app teams on the Goldsky blog.

How to move a Mirror pipeline to Turbo

These steps follow the Mirror to Turbo migration guide (opens in a new tab).

Step 1: Prepare

Install the latest Goldsky CLI. Turbo commands live under goldsky turbo, a separate namespace from Mirror's goldsky pipeline commands. Export the current Mirror pipeline definition to see the YAML to translate:

goldsky pipeline get <name>

Step 2: Translate the YAML

Turbo's YAML looks like Mirror's, with a few changes:

• Drop the top-level apiVersion: 3 field. Turbo does not use it.
• resource_size and name carry over unchanged.
• Sources still use type: dataset, but Turbo adds start_block and end_block for block ranges, and start_at: latest or start_at: earliest for the starting position.
• Postgres sinks change their secret format. Mirror uses a JSON object (type, host, port, and so on). Turbo uses a connection string (postgres://user:pass@host:port/db). Create a new secret with goldsky secret create.
• SQS sinks change type: sqs to type: sqs_sink.
• Kafka sinks add a required data_format field, and move schema_registry_url out of the sink config and into the Kafka secret.

EVM datasets with uint256 or int256 values, such as value or balance, land in Postgres as NUMERIC(78, 0) under Turbo. An existing Postgres table from a Mirror pipeline may use a different column type. In that case, migrate the column, or drop the table and let Turbo recreate it.

Step 3: Validate and inspect before cutover

Validate the translated YAML without deploying it:

goldsky turbo validate path/to/pipeline.yaml

Then watch data flow through each step before pointing the pipeline at production sinks:

goldsky turbo inspect path/to/pipeline.yaml

Swap in the blackhole sink to try this step. It gives a quick sanity look at the output.

Step 4: Pick a cutover strategy

Mirror's processed-data state does not carry over to Turbo. Goldsky documents three strategies:

• Run both in parallel (recommended). Deploy Turbo with start_at: latest on every source, so it starts at the chain tip. Leave Mirror running. Once Turbo's writes look healthy, pause the Mirror pipeline with goldsky pipeline pause . After a buffer period, delete the Mirror pipeline. This approach needs a sink that can absorb duplicate writes, such as Postgres with primary keys.
• Block-number cutover. Pick a future block, stop Mirror there with a SQL filter, and start Turbo at the next block using start_block. This gives a clean handoff with no duplicate writes, for sinks that cannot dedupe.
• Cold cutover. Pause Mirror, deploy Turbo with start_at: latest, and accept a short gap in the sink. Simplest, but blocks in the gap are lost.

Step 5: Decommission Mirror

After the Turbo pipeline runs cleanly through a verification window, delete the Mirror pipeline:

goldsky pipeline delete <mirror-pipeline-name>

Shared Mirror secrets can stay in place. Delete unused ones with goldsky secret delete.

FAQ

Is Mirror still supported?
Goldsky retired Mirror on 2026-08-19. Existing Mirror pipelines keep running, but Goldsky treats Mirror as legacy and directs new work to Turbo.

Does every Mirror pipeline migrate to Turbo?
About 95% do, with a 1:1 mapping. The rest depend on subgraph entity sources, an Elasticsearch, Timescale, DynamoDB, or Snowflake sink, or Mirror's payload_columns option. Turbo does not support any of these yet.

Does Turbo support Solana?
Yes. Solana, Bitcoin, Stellar, and NEAR sources are Turbo-only. Mirror never supported them.

Will a Turbo pipeline replay data Mirror already processed?
Not automatically. Mirror's processed-data state does not carry over. Pick a cutover strategy first. Three options: run both in parallel, cut over at a specific block, or accept a short gap. See the cutover-strategy section above.

Do Mirror SQL transforms need a rewrite for Turbo?
Most do not. Turbo runs SQL transforms on Apache DataFusion instead of Flink. Goldsky ports Mirror's _gs_* UDFs over too, so most Mirror SQL works as-is.

What powers Turbo?
Streamling, Goldsky's open-source runtime built in Rust on Apache Arrow and Apache DataFusion. It replaced the Apache Flink system behind Mirror. Pipelines start in under 5 seconds. In Goldsky's benchmark, they use over 30x less compute than on Flink.