<p>In terms of performance there's not much of a difference between a entries and categories. They're both <a href="https://craftcms.com/docs/3.x/elements.html" rel="nofollow noreferrer">elements</a> so their database queries have similar structures and overheads. Differences in performance, if any, will be so small you won't ever notice them.</p>
<p>Much more important in terms of performance is that you make sure to properly optimize your queries. For the page that lists speakers with their corresponding events, make sure to use <a href="https://craftcms.com/docs/3.x/dev/eager-loading-elements.html" rel="nofollow noreferrer">eager-loading</a> for the events. This way, you can retrieve the speakers and their associated events in one query, instead of needing an additional query for each speaker. On top of that, make sure to <a href="https://craftcms.com/docs/3.x/dev/tags.html#cache" rel="nofollow noreferrer">cache</a> the output of that page to avoid an expensive query for every page load.</p>
<p>Since performance isn't a factor for the decision between categories and entries in this case, I would just chose whatever makes more sense semantically. In this case, I'd say a list of speakers should be a section (channel). But it also depends on your further data structure requirements.</p>
<blockquote>
<p>And Should I stay with twig or change to json or graphql for quering that much data.</p>
</blockquote>
<p>This is unanswerable without knowing your requirements. If you don't need a dynamic frontend / SPA, stick with SSR (server-side rendering) using Twig templates. GraphQL and/or REST APIs coupled to a frontend introduces a lot of unnecessary overhead, I wouldn't go down that route if I didn't have a good reason to. Besides, SSR will always be faster than a single page application.</p>

CC BY-SA 4.0
2023-11-05T19:54:06.617Z
I have a further question for the scenario: with regard to performance: is it better to work with entries and relationships, so each speaker has a reversed relationship to an event. 
Or is it also a good idea to work with a matrix field inside an event. So that one event can have multiple speakers inside a matrix field. Without any (reversed) relationship. 
To display a list of speaker I have to query the matrix field than. 
Coming from wordpress i know that it is not a good idea to query repeater fields but how is it in craft?
buckdanny
CC BY-SA 4.0
2023-11-06T10:09:27.340Z
@buckdanny It's much better to use a simple relationships and not go through Matrix. I would use a single `Entries` field on the events where you can select one or multiple speakers. You can select multiple entries in a single field, so you don't need Matrix to have multiple speakers. This will allow you to easily query all speakers for a given event. And it's also trivial to find all events a given speaker is related to, see the [Docs on Relations](https://craftcms.com/docs/4.x/relations.html) for details. Going through Matrix is also possible, but usually unnecessary.
MoritzLost
CC BY-SA 4.0
2023-11-14T19:59:55.897Z
thank you very much! I have overthought it a bit. I was also unsure because of the upcoming "entrification" of the Matrix fields. Vielen Dank lieber Moritz! Auch für den tollen Talk auf der dot all!
buckdanny
CC BY-SA 4.0
2023-11-15T08:26:08.957Z
@buckdanny Gern geschehen! :)
MoritzLost
CC BY-SA 4.0
2022-02-03T14:12:00.553Z
2022-02-03T14:26:06.037Z
2022-02-03T14:26:06.037Z
MoritzLost
<p>Sorry for this general question, i am building a large archive site with many (&gt;1000) Events. Every Event has one or more Speaker. At the moment I am using two channels: &quot;events&quot; and &quot;speakers&quot; and work with relationships.
My question is, is it better (in terms of performance) to work with categories for the speakers?
The Website will have a long list with all speakers (&gt;1000) and all events. Doing so, i have to query a lot of data.</p>
<p>John Doe</p>
<ul>
<li>Event 1</li>
<li>Event 2</li>
</ul>
<p>At the moment i am working in twig, but maybe I will change to work with json data, generated by the element api or maybe graphl. Whatever will be the most performative solution. So kind of a general question here: categories or channel for the speaker? And Should I stay with twig or change to json or graphql for quering that much data.</p>

<categories><query><channels>
Events with Speaker: Categories or Channel
# Events with Speaker: Categories or Channel

(Asked by: username_0 on 2022-02-03)

Sorry for this general question, i am building a large archive site with many (>1000) Events. Every Event has one or more Speaker. At the moment I am using two channels: "events" and "speakers" and work with relationships.
My question is, is it better (in terms of performance) to work with categories for the speakers?
The Website will have a long list with all speakers (>1000) and all events. Doing so, i have to query a lot of data.

John Doe

* Event 1
* Event 2

At the moment i am working in twig, but maybe I will change to work with json data, generated by the element api or maybe graphl. Whatever will be the most performative solution. So kind of a general question here: categories or channel for the speaker? And Should I stay with twig or change to json or graphql for quering that much data.

**Tags:** categories, query, channels


---

## 1 answers

### Answer by username_1 on 2022-02-03. Score: 1 | Accepted answer

In terms of performance there's not much of a difference between a entries and categories. They're both [elements](https://craftcms.com/docs/3.x/elements.html) so their database queries have similar structures and overheads. Differences in performance, if any, will be so small you won't ever notice them.

Much more important in terms of performance is that you make sure to properly optimize your queries. For the page that lists speakers with their corresponding events, make sure to use [eager-loading](https://craftcms.com/docs/3.x/dev/eager-loading-elements.html) for the events. This way, you can retrieve the speakers and their associated events in one query, instead of needing an additional query for each speaker. On top of that, make sure to [cache](https://craftcms.com/docs/3.x/dev/tags.html#cache) the output of that page to avoid an expensive query for every page load.

Since performance isn't a factor for the decision between categories and entries in this case, I would just chose whatever makes more sense semantically. In this case, I'd say a list of speakers should be a section (channel). But it also depends on your further data structure requirements.

> And Should I stay with twig or change to json or graphql for quering that much data.

This is unanswerable without knowing your requirements. If you don't need a dynamic frontend / SPA, stick with SSR (server-side rendering) using Twig templates. GraphQL and/or REST APIs coupled to a frontend introduces a lot of unnecessary overhead, I wouldn't go down that route if I didn't have a good reason to. Besides, SSR will always be faster than a single page application.

> **Comments:**
> **username_0**: I have a further question for the scenario: with regard to performance: is it better to work with entries and relationships, so each speaker has a reversed relationship to an event.  Or is it also a good idea to work with a matrix field inside an event. So that one event can have multiple speakers inside a matrix field. Without any (reversed) relationship.  To display a list of speaker I have to query the matrix field than.  Coming from wordpress i know that it is not a good idea to query repeater fields but how is it in craft?  
> **username_1**: @username_0 It's much better to use a simple relationships and not go through Matrix. I would use a single `Entries` field on the events where you can select one or multiple speakers. You can select multiple entries in a single field, so you don't need Matrix to have multiple speakers. This will allow you to easily query all speakers for a given event. And it's also trivial to find all events a given speaker is related to, see the [Docs on Relations](https://craftcms.com/docs/4.x/relations.html) for details. Going through Matrix is also possible, but usually unnecessary.  
> **username_0**: thank you very much! I have overthought it a bit. I was also unsure because of the upcoming "entrification" of the Matrix fields. Vielen Dank lieber Moritz! Auch für den tollen Talk auf der dot all!  
> **username_1**: @username_0 Gern geschehen! :)  

---

