---
title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
sidebarTitle: 'Pruning with indexerHints'
---

## TLDR

[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the Subgraph’s database up to a given block, and removing unused entities from a Subgraph’s database will improve a Subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a Subgraph.

## How to Prune a Subgraph With `indexerHints`

Add a section called `indexerHints` in the manifest.

`indexerHints` has three `prune` options:

- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all Subgraphs created by `graph-cli` >= 0.66.0.
- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.

We can add `indexerHints` to our Subgraphs by updating our `subgraph.yaml`:

```yaml
specVersion: 1.3.0
schema:
  file: ./schema.graphql
indexerHints:
  prune: auto
dataSources:
  - kind: ethereum/contract
    name: Contract
    network: mainnet
```

## Important Considerations

- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.

- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).

## Conclusion

Pruning using `indexerHints` is a best practice for Subgraph development, offering significant query performance improvements.

## Subgraph Best Practices 1-6

1.  [Improve Query Speed with Subgraph Pruning](/subgraphs/best-practices/pruning/)

2.  [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/best-practices/derivedfrom/)

3.  [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/best-practices/immutable-entities-bytes-as-ids/)

4.  [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/best-practices/avoid-eth-calls/)

5.  [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/best-practices/timeseries/)

6.  [Use Grafting for Quick Hotfix Deployment](/subgraphs/best-practices/grafting-hotfix/)
