> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sqd.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Best practices

> Best practices for building production-ready indexers

A short checklist for making your squid fast, correct and cheap to run. Most of the items below link to a dedicated page with details.

## Process data in batches

Make sure that you use [batch processing](./advanced/batch-processing) throughout your code: transform data in memory over the whole batch and persist it with a small number of batched `upsert`/`insert` calls. Avoid loading or saving single entities unless strictly necessary. Consider using `@belopash/typeorm-store` for large projects with extensive [entity relations](../reference/schema-files/entity-relations) and frequent [database reads](../reference/data-stores/typeorm-store#typeorm-methods).

## Select only the fields you need

Data requests are configured at the processor level. Use `setFields` to request only the fields your handler actually reads — see [field selection](../reference/evm-stream/field-selection). Requesting fewer fields means smaller responses from the data source and faster syncing. The same discipline applies to data requests themselves: subscribe only to the addresses, topics or calls you process.

## Filter data in the batch handler

Even when your processor configuration requests data from particular contracts or addresses, check in the batch handler that each data item matches what your processing code expects (e.g. that the `address` field of a log matches the contract address before decoding it). This ensures that future changes to the processor configuration will not silently route newly added data to your old processing code.

## Index your database

If your squid [saves its data to a database](./writing-to-postgres), make sure your [schema](../reference/schema-files/schema-files-codegen) has [`@index` decorators](../reference/schema-files/indexes-constraints) for all entities that will be looked up frequently.

* Follow the [queries optimization procedure](/en/cloud/resources/query-optimization) for best results.
* If your squid repeatedly rewrites the same rows (per-block prices, TVL, balances, positions, etc.), [tune those update-heavy tables](/en/cloud/resources/update-heavy-tables) so the updates stay cheap and the tables don't bloat over time.

## Harden your GraphQL API

If your squid serves a [GraphQL API](./serving-graphql):

1. Do not use [OpenReader](./serving-graphql#openreader) if your application uses subscriptions. Instead, use [PostGraphile](./serving-graphql#postgraphile) or [Hasura](./serving-graphql#hasura).
2. If you do use OpenReader, configure the built-in [DoS protection](../reference/openreader/configuration/dos-protection) against heavy queries and set up [caching](../reference/openreader/configuration/caching).
3. If you use PostGraphile or Hasura, follow their docs to harden your service in a similar way.

## Prepare for production deployment

If you deploy to SQD Cloud, go through the [Cloud best practices checklist](/en/cloud/resources/best-practices): a professional organization, dedicated resources, an adequate [`scale:` section](/en/cloud/reference/scale), [zero-downtime updates](/en/cloud/resources/slots-and-tags#zero-downtime-updates), [secrets](/en/cloud/resources/env-variables#secrets) for all sensitive data and proper [logging](/en/cloud/resources/logging).