---
title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
sidebarTitle: 'Arrays with @derivedFrom'
---

## TLDR

Arrays in your schema can really slow down a Subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.

## How to Use the `@derivedFrom` Directive

You just need to add a `@derivedFrom` directive after your array in your schema. Like this:

```graphql
comments: [Comment!]! @derivedFrom(field: "post")
```

`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the Subgraph more efficient.

### Example Use Case for `@derivedFrom`

An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.

Let’s start with our two entities, `Post` and `Comment`

Without optimization, you could implement it like this with an array:

```graphql
type Post @entity {
  id: Bytes!
  title: String!
  content: String!
  comments: [Comment!]!
}

type Comment @entity {
  id: Bytes!
  content: String!
}
```

Arrays like these will effectively store extra Comments data on the Post side of the relationship.

Here’s what an optimized version looks like using `@derivedFrom`:

```graphql
type Post @entity {
  id: Bytes!
  title: String!
  content: String!
  comments: [Comment!]! @derivedFrom(field: "post")
}

type Comment @entity {
  id: Bytes!
  content: String!
  post: Post!
}
```

Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.

This will not only make our Subgraph more efficient, but it will also unlock three features:

1. We can query the `Post` and see all of its comments.
2. We can do a reverse lookup and query any `Comment` and see which post it comes from.

3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our Subgraph mappings.

## Conclusion

Use the `@derivedFrom` directive in Subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.

For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).

## 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/)
