Docs
Search⌘ K
  • Home
  • About The Graph
  • Supported Networks
  • Protocol Contracts
  • Subgraphs
    • Substreams
      • Token API
        • Indexing
          • Resources
            Subgraphs > Best Practices

            2 minutes

            Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning

            TLDR

            Pruning 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 are desired.

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

            1specVersion: 1.3.02schema:3  file: ./schema.graphql4indexerHints:5  prune: auto6dataSources:7  - kind: ethereum/contract8    name: Contract9    network: mainnet

            Important Considerations

            • If 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 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

            2. Improve Indexing and Query Responsiveness by Using @derivedFrom

            3. Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs

            4. Improve Indexing Speed by Avoiding eth_calls

            5. Simplify and Optimize with Timeseries and Aggregations

            6. Use Grafting for Quick Hotfix Deployment

            ⁠Edit on GitHub⁠

            Smart Contract Analysis with Cana CLIArrays with @derivedFrom
            On this page
            • TLDR
            • How to Prune a Subgraph With indexerHints
            • Important Considerations
            • Conclusion
            • Subgraph Best Practices 1-6
            The GraphStatusTestnetBrand AssetsForumSecurityPrivacy PolicyTerms of Service