SQD

• Name: SQD
• URL: https://sqd.dev/
• Category: blockchain-data extraction infrastructure / decentralized data lake / streaming access control plane
• Summary: SQD is a layered blockchain-data control plane: replicated Parquet-form history, a shared Portal API, two distinct developer paths, and an optional managed cloud layer on top. The important move is not faster data; it is splitting custody, access, and workflow control into separate surfaces.
• What it does:
  • Runs a decentralized worker network that stores and serves blockchain data with replication across independent operators
  • Exposes a shared Portal streaming API that returns pre-decoded blockchain data over HTTP/NDJSON rather than ordinary JSON-RPC polling
  • Provides the Squid SDK for batch-style ETL indexers and the Pipes SDK for composable stream-to-warehouse pipelines
  • Supports arbitrary historical backfill and live streaming from the same data plane, spanning EVM chains plus Solana, Bitcoin, and Hyperliquid
  • Offers managed deployment and operations through SQD Cloud while keeping lower-layer worker software and major SDK components open source
  • Uses Portal, Cloud, and network-token economics as separate control surfaces above the replicated data lake
• Key claims:
  • SQD’s current materials explicitly frame the system as enterprise-grade onchain data infrastructure with validated, real-time blockchain data from 225+ networks through a single streaming API, which is the clearest reason to catalog it as a data-plane protocol stack rather than a generic analytics vendor.
  • The most reusable mechanism insight is the architectural split between the decentralized data lake and the access layer above it. Worker nodes store immutable Parquet chunks with multi-operator replication, while Portal becomes the practical gateway most users query.
  • The Portal API is analytically important because it standardizes access around HTTP streaming and pre-decoded data instead of raw node semantics. That shifts operational power away from archive-node ownership alone and toward whoever controls portal routing, quotas, defaults, and schema normalization.
  • The split between Squid SDK and Pipes SDK matters because SQD is not only selling one indexing framework. One path favors application-owned ETL/indexer workflows, while the other favors direct streaming into external warehouses and data systems. Those are different dependency shapes and different rent surfaces.
  • The docs also make Cloud a separate layer rather than the whole product. Teams can consume the underlying network/API stack while still deciding whether to accept SQD-managed deployment, scaling, and monitoring. That distinction would be lost if SQD were archived as a generic indexer company.
  • The former Subsquid branding still matters because older repos, links, and package names remain under the subsquid namespace, while current public branding and docs are now centered on SQD. That naming split is relevant for source discovery and for judging continuity across the network, SDK, and business layers.
  • SQD belongs in the active corpus because it provides a useful comparison layer between Firehose-style extraction stacks, Substreams-style transformation pipelines, and The Graph-style app-facing query layers. The main question is where control sits once raw chain history has already been normalized, replicated, and made streamable.
• Whitepaper: No classic whitepaper surfaced in this pass. The strongest primary materials were SQD’s current docs corpus, llms-full.txt architecture overview, and the public Squid SDK repository; see ../whitepapers/sqd-primary-sources-2026-05-14.md.
• Sources:
  • https://sqd.dev/
  • https://sqd.dev/llms-full.txt
  • https://docs.sqd.dev/en/sdk/squid-sdk/how-to-start/squid-from-scratch.md
  • https://raw.githubusercontent.com/subsquid/squid-sdk/master/README.md

Internal linkages

• Strongest comparisons: firehose, the-graph, and substreams

Control surface

• The leverage sits in worker participation, replication, Portal defaults, schema normalization, quota policy, and the separate Cloud packaging layer.

• That is the useful cut. SQD is a data-custody and access stack wrapped around blockchain history, not a neutral mirror of it.

• More of the story is in the underlying network and access architecture than in one hosted query product.

• Last reviewed: 2026-06-02 UTC