Squid SDK: Installing the TypeScript ETL toolkit

Why Squid SDK sits below an indexing application

Squid SDK addresses the data extraction and transformation layer of a blockchain indexer. It is aimed at developers who need to define their own ETL flow rather than adopt a ready-made indexing application. The README explicitly distinguishes it from systems such as TheGraph and Ponder: Squid SDK is a toolkit, while those projects are described as indexing apps. That distinction matters because the SDK does not remove decisions about chain processing, decoded data, storage, schema, and deployment.

The documented chain scope covers Ethereum and Ethereum-compatible networks, Substrate-based chains, and Solana. This is useful for teams that want one TypeScript framework across those ecosystems, although the README does not imply that every processor has identical features. Chain-specific code still matters because accounts, transactions, events, and runtime data models differ between EVM chains, Substrate chains, and Solana.

SQD Network is the other defining part of the design. The README describes it as a decentralized data lake and query engine from which clients can select subsets of block data and stream them. Instead of defining the SDK only as a local decoder, this gives it a documented data-sourcing model. It also creates a boundary for adoption: the repository states native support for SQD Network, but the README does not document an independent direct-RPC configuration.

TypeScript processors and binary data decoding

The repository is a Rush monorepo with separate areas for `evm/`, `solana/`, `substrate/`, and shared packages under `processor/`, `util/`, and `graphql/`. Based on that layout, Squid SDK is organized as a collection of chain processors and supporting libraries rather than one monolithic application. The root also contains directories for other networks, but the README names Ethereum-compatible networks, Solana, and Substrate as the supported scope, so additional directories should not be treated as proof of equivalent user-facing support.

The README names two technical characteristics: binary data codecs and type-safe access to decoded data. Binary codecs are relevant when an indexer receives compact encoded block data and needs to turn it into structured values. Type-safe decoded access then matters in the processor logic, where chain objects and fields are consumed by application code. This is a more precise claim than general performance language. The documentation does not provide codec examples, supported type definitions, error behavior, or a per-chain feature matrix.

SQD Network supplies the streaming source described by the project. The conceptual data flow is source selection, block-data transfer, decoding, and then user-defined ETL processing. The README does not show how a processor subscribes to ranges, how schema changes are handled, or how the decoded result reaches a database. Those implementation steps belong to the linked full documentation and the generated project guide. This makes the README useful for identifying the architecture, but insufficient as a standalone API reference.

Installing the CLI and creating the first Squid project

The README gives a two-command quickstart. It installs the SQD CLI globally and uses `sqd init` to scaffold a project named `my-squid`:

npm install -g @subsquid/cli
sqd init my-squid

The first command makes `sqd` available on the command line. The second starts the interactive project creation flow, which should generate the initial TypeScript project structure under `my-squid`. The README does not list prompts, non-interactive flags, supported Node.js versions, or example answers for that flow, so those details cannot be assumed.

After scaffolding, the project directs developers to the “How to start” guide. The README contains no processor initialization code, schema definition, database connection, or deployment command beyond the scaffold step. Consequently, the first verified use available from the README is project creation rather than a complete indexing run. A reader who needs to ship an indexer must follow the linked guide and confirm that it provides a processor configuration for the intended chain.

For contributors working on Squid SDK itself, the repository uses a separate installation path. The `Dockerfile` copies the monorepo into `/squid` and runs the checked-in Rush installer:

ADD . .
RUN --mount=type=cache,id=pnpm-store,target=/squid/common/temp/pnpm-store \
    node common/scripts/install-run-rush.js install

That build operation belongs to repository development, not to creating an application with the SQD CLI. Keeping those workflows separate avoids treating a contributor build as a production installation of the SDK.

Rush monorepo packaging and release management

Squid SDK is managed with Rush, as stated in the repository’s change-management instructions. Contributors modify packages within the monorepo, then create a change file relative to `origin/master`:

rush change -b origin/master

The command opens an interactive process for selecting `major`, `minor`, `patch`, or `none`. The README defines `major` as a breaking change requiring customer code updates, `minor` as a backward-compatible feature, `patch` as a bug fix or small improvement, and `none` as an internal change with no public API effect. Generated files are placed under `common/changes/@subsquid/[package-name]/` and are later used to generate changelogs.

This process reveals an important adoption cost. Squid SDK is a collection of packages, so developers may need to watch release notes and changes across the processor and utility packages used by a project. It also means that the `@subsquid/cli`, individual processor packages, and supporting packages can have separate release identities. The README does not provide a compatibility matrix or instructions for pinning all packages to one release, so exact dependency alignment cannot be confirmed from it.

The repository is not archived, and its last push was on 2026-10-14. Releases are listed for 2026-08-27, 2026-07-30, and 2026-05-11. Those facts indicate recent repository and release activity, but they do not establish that every processor evolves at the same rate. Package-level release notes should be checked when dependency updates matter.

Apache-2.0 licensing and operational boundaries

The repository is licensed under Apache-2.0. That license permits use, modification, and distribution subject to its terms, including preservation of notices and the license conditions. This is a factual summary of the identified license, not legal advice. Teams should review the repository’s `LICENSE` file and their own compliance obligations when embedding the SDK or distributing modified packages.

The clearest operational limitation is the documentation’s emphasis on SQD Network as the native source. The README describes selecting and streaming subsets of block data through that network, but it does not say how to configure an RPC endpoint as an alternative. That does not prove direct RPC is impossible. It does mean the README does not establish it as a supported path. A team with strict network-isolation, node-routing, or data-residency requirements should verify the source configuration before committing.

There is another documentation boundary around outputs. Although the repository includes `typeorm/`, `graphql/`, and Docker build content, the README does not explain which databases are officially supported by generated applications or whether every chain processor supports the same destination. The repository layout is evidence of code organization, not a complete support guarantee. Migration strategy, reorganization handling, checkpoint storage, and production rollback procedures are also absent from the README.

Squid SDK is therefore a poor first choice for someone who wants a hosted indexer with all decisions already made. It fits better when the team wants direct control over TypeScript processing and can follow chain-specific documentation.

SQD Network sourcing versus custom extraction pipelines

The closest documented alternative is a custom ETL pipeline built directly against blockchain node interfaces, such as an EVM JSON-RPC endpoint, without relying on SQD Network’s subset-selection and streaming model. This is a real architectural difference, although the README does not name a specific competing framework to configure.

Squid SDK supplies a TypeScript toolkit, chain processors, binary codecs, decoded-data types, and native integration with SQD Network. A custom pipeline would place responsibility for node access, block-range retrieval, decoding, retry policy, and normalization inside the application or its chosen libraries. Squid SDK can reduce that implementation burden when its processors match the target chain. The custom approach offers greater control over infrastructure but requires the team to assemble and operate those parts.

For an Ethereum-like chain covered by the SDK’s documented support, teams should compare the processor’s documented features with their custom requirements before deciding. Solana developers face a separate processor and must confirm equivalent support for the required data types. Substrate users may need runtime-specific decoding beyond basic chain data. The README gives no detailed comparison, so the correct first check is not package count or popularity. It is whether the generated processor can retrieve the exact entities and fields required by the destination schema.

Editorial conclusion

Developers building custom TypeScript indexers should evaluate Squid SDK when SQD Network covers their chain and data needs. Projects requiring a fully standalone extraction path or an already configured indexing application should first verify that the supported processor and destination database are documented for their target chain. The clearest first adoption check is whether the documentation provides a complete processor setup and deployment path for that exact chain.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. subsquid/squid-sdk on GitHub