Batches, not events
Every stage of a squid — extraction, decoding, transformation, persistence — operates on batches of blocks rather than one event at a time. Handlers receive many blocks at once, decode what they need, and write results with a single database call per batch. This is the main reason squids sync one to two orders of magnitude faster than event-callback indexers: the database sees a handful of large transactions instead of millions of small ones.Code, not configuration
The data handler is plain TypeScript. There is no DSL and no sandbox — you can call external APIs, use any npm package, keep in-memory state across batches, and structure the project like any Node.js application. The trade-off is explicitness: you request exactly the data items and fields you need, and you write the transformation yourself, with generated typings keeping the decoding type-safe.Modular pipeline
A squid composes independent parts — a Solana data source, a store (PostgreSQL, files, BigQuery), optional code generators, and an optional GraphQL server — connected by narrow interfaces. Any store works with any source, and custom implementations plug in at every seam. Data comes primarily from the SQD Network, which serves pre-filtered data far faster and cheaper than chain nodes — including real-time unfinalized blocks.What it’s good for
Squid SDK is a batteries-included framework that shines when you need to get from an idea to a GraphQL API or Postgres tables fast. In many aspects it’s similar to other popular indexing frameworks like TheGraph, Ponder and Envio. If you want a similar self-contained framework that works with the Portal API, Squid SDK is the right choice. Consider the alternatives if- you want an approach that allows you to more readily split your requests and transforms into modules, then mix and match them - see Pipes SDK;
- you need more flexibility than Squid SDK allows - see Pipes SDK or raw Portal API.