# Performance issues with collection queries in workspaces

**URL:** <https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217>\
**Category:** Help me!\
**Created:** [July 1, 2025, 4:05pm UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217 "2025-07-01T16:05:17Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sergior](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/sergior/32/73_2.png) [@sergior](https://community.forestadmin.com/u/sergior)\
**Post date:** [July 1, 2025, 4:05pm UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/1 "2025-07-01T16:05:17Z")

</div>

## Feature(s) impacted

Workspaces - I have a component in a workspace that allows filtering customers. Based on the search results the customer details are displayed in the section below

 ![Screenshot 2025-07-01 at 16.45.45](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/d/d4d0abda8825f1dfda68647292691a65ccb1cb6c.png)

## Observed behavior

The query performed to the database to display the details of the customer found does a LEFT JOIN with **all** the customer associations, regardless if those associations are needed to display the customer details or not (in the screenshot, the address is the single association that is required but we have more that we don’t need for this component)

We keep receiving slow query alerts in our error tracking system because these queries are causing performance issues on our database as they are doing a lot of unnecessary costly joins.

On the normal list/details views for the customer I don’t observe this behaviour.

## Expected behavior

The query performed to the database to retrieve the customer details should only use LEFT JOINS for the associations that are being displayed in the customer details component.

## Context

- Project name: Back Office
- Team name: Customer Operations
- Workspace: Customer Success Workspace
- Environment name: can be reproduced in all environments but production is the one severely affected by
- Database type: Postgresql

**And, if you are self-hosting your agent:**

- Agent technology: Ruby
- Agent (forest package) name & version (from your .lock file): 9.11.3

---

<div class="post-metadata">

**Author:** ![anon62739609](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@anon62739609](https://community.forestadmin.com/u/anon62739609)\
**Post date:** [July 2, 2025, 8:32am UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/2 "2025-07-02T08:32:40Z")

</div>

Hi @sergior,  
on our oldest agent all the belongs to were fetched.  
You will need to migrate to our new agent `forest_admin_rails`, you can find the documentation here: [Quick start | Ruby Developer Guide](https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/quick-start)

---

<div class="post-metadata">

**Author:** ![sergior](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/sergior/32/73_2.png) [@sergior](https://community.forestadmin.com/u/sergior)\
**Post date:** [July 2, 2025, 12:36pm UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/3 "2025-07-02T12:36:05Z")

</div>

Hi @anon62739609 , thanks for your answer.

Is there an actual **migration** from the existing agent documentation? The link you have provided: [https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/quick-start/quick-start-rails](https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/quick-start/quick-start-rails) seems like it’s doing a setup from scratch?

If that’s still the correct link, there’s a step in it where I’m not sure where to get the following information:

```javascript
rails g forest_admin_rails:install THE-KEY-PROVIDED-BY-FORESTADMIN

```

Are you supposed to send us this key?

Kind regards,  
Sergio

---

<div class="post-metadata">

**Author:** ![matthv](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/matthv/32/3269_2.png) [@matthv](https://community.forestadmin.com/u/matthv)\
**Post date:** [July 2, 2025, 12:57pm UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/4 "2025-07-02T12:57:06Z")

</div>

Hello @sergior

You can follow this [migration guide](https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/migrating/steps) to migrate your agent to the new ruby agent architecture.

As part of the migration, you’ll need to run the following command : `rails g forest_admin_rails:install`. This command requires your `ENV_SECRET`

---

<div class="post-metadata">

**Author:** ![sergior](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/sergior/32/73_2.png) [@sergior](https://community.forestadmin.com/u/sergior)\
**Post date:** [July 3, 2025, 10:28am UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/5 "2025-07-03T10:28:37Z")

</div>

Thanks for the suggestion, I hope I will be able to migrate to this new agent soon. The agent is stil in beta though, so is there any considerations to take while migrating aside from what is already covered in the missing features: [https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/migrating#missing-features](https://docs.forestadmin.com/developer-guide-agents-ruby/getting-started/migrating#missing-features) ?

---

<div class="post-metadata">

**Author:** ![matthv](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/matthv/32/3269_2.png) [@matthv](https://community.forestadmin.com/u/matthv)\
**Post date:** [July 3, 2025, 12:17pm UTC](https://community.forestadmin.com/t/performance-issues-with-collection-queries-in-workspaces/8217/6 "2025-07-03T12:17:34Z")

</div>

By the way, I noticed you’re currently on version 9.11.3, before migrating to the new agent, you could try bumping to the latest 9.14.5, which includes several fixes that could help improve query performance.  
There are no breaking changes between these patch versions, so it should be a safe update.
