Since the issue occurs only for one user role, while other roles load the same page immediately, I would investigate entity access/XPath constraints for that role first, rather than the Data Grid itself.

After the Mendix 8 → 9 upgrade, the generated database queries may differ, and a complex access rule can become much more expensive when retrieving ~3,000 objects.

I would check:

1. Compare the affected role's entity access rules/XPath constraints with a role that loads the page quickly.
2. Temporarily test the affected role with the same entity access as a working role. If the page becomes fast, you've isolated the problem.
3. Look especially for XPath constraints that traverse multiple associations, use [%currentUser%], or contain several conditions.
4. Check whether the indexes support not only the sorting attribute, but also attributes/associations involved in the filtering/access constraint.

The strongest clue here is:

Same entity + same page + same database + different role = very different performance.

That makes role-specific entity access/security constraints a strong candidate.

Please accept this solution if it helps

Likely cause: Entity access (XPath) constraints, not the widgets themselves.

Studio Pro 9 enforces module role XPath constraints on entity access more strictly than 8.x — especially constraints that reference associated entities. Since the slowdown is role-specific, check whether that one role has an XPath constraint on the entity (or its associations) that other roles don't have (admin often bypasses it).

To confirm & fix:

1. Go to entity Access rules → find the constraint applied to that specific role's module role.
2. If the constraint traverses an association (e.g. [Association/Entity/Attribute = ...]), that's your culprit — Mendix 9 wraps this in a subquery that often can't use your existing index.
   • Fix options:Add a database index on the foreign key / association column used in the constraint (not just the sort attribute).
   • Simplify the constraint — avoid multi-hop associations in XPath where possible; denormalize a flag/attribute onto the entity itself if feasible.
   • If constraint logic is complex, replace the DB data source with a microflow data source using a proper OQL/Retrieve with explicit range + sort — gives you full control over the query plan.
3. Enable query logging temporarily (com.mendix.core → Trace/Debug or use the Performance tab in Studio Pro / runtime logs) to capture the actual generated SQL for that role and compare it against another role — this will show exactly where the extra JOIN/subquery is coming from.

This pattern (role-specific slowness after 8→9 upgrade with Data Grid/List View) is a commonly reported regression tied to XPath-based entity access, not a widget/pagination issue — your indexing and pagination setup is already correct.

Hi,

Since the page is fast for the other roles and slow only for one specific role, I would first look at the entity access rules for that role rather than the Data Grid itself.

Even with only ~3,000 objects, a Data Grid/List View can become slow if the user's role causes additional or complex XPath constraints to be added to the database query. This is especially worth checking when the data source is directly from the database.

I would troubleshoot it in this order:

1. Compare the security of the affected role with a working role

Check the entity access rules for the entity shown in the Data Grid and all entities involved in the relevant associations.

Pay particular attention to XPath constraints such as:

[SomeAssociation/OtherEntity = $currentUser/...]

or multiple access rules for the same entity/module role.

Mendix combines applicable access rules for a user, so a role with more/different module roles can result in a more complex query than another role. Complex security XPath is one of the documented causes of slow database retrieves.

2. Check the generated database queries

Rather than guessing from the page configuration, I would enable query-duration logging temporarily in the affected environment.

For example, set:

LogMinDurationQuery = 500

and inspect the ConnectionBus_Queries log node.

This will show queries taking longer than the configured threshold. Mendix specifically recommends LogMinDurationQuery for identifying slow XPath/OQL queries.

Then reproduce the issue using the affected role and compare the logged queries with the same page opened using a role that loads normally.

3. Check the indexes used by the security XPath

You mentioned that indexes already exist for the attributes used for sorting, which is good, but I would also check the attributes used in access-rule XPath constraints and page filters.

An index that helps the Data Grid sorting does not necessarily optimize the security constraint.

Mendix recommends indexing attributes used in XPath expressions for read-intensive entities, especially when the entity contains a substantial number of records.

4. Check whether the role has multiple applicable access rules

This is an easy one to overlook. For example, if a role receives access through several rules containing different XPath constraints, the resulting database query can become considerably more complex.

Mendix specifically calls out duplicated/complex access rules as a performance concern and recommends simplifying/consolidating the security rules where possible.

I would also check whether the affected user has multiple module roles assigned through the user role configuration. The combination of those roles can make the security query different from the query generated for the other users.

5. Check the Data Grid itself

If the query logs don't show a slow database retrieve, then I would move up to the UI side:

• Data Grid/List View data source
• number of nested data views/list views
• reference selectors/dropdowns on the page
• calculated attributes
• additional data sources loaded when the page opens
• whether the grid is being refreshed/reloaded more than once

Mendix recommends using the browser developer tools to distinguish between a slow retrieve and simply having too many requests during page loading.

One other thing I would test is putting a breakpoint on the Data Grid's data-source microflow, if it has one. If it is a database data source, the query logging approach above is more useful.

Regarding the 8 → 9.24 upgrade: I wouldn't assume that the upgrade itself is the root cause yet. There have been performance-related fixes and changes throughout the 9.24 line, but the fact that only one security role is affected makes the generated query/security constraints the first thing I would investigate.

So my first test would be:

same page + same data + working role vs affected role → compare ConnectionBus_Queries output.

If the affected role produces a significantly slower query, you have a concrete starting point: inspect and simplify the XPath/access rules and add the required indexes rather than changing the Data Grid configuration.

With only ~3,000 objects, I would not consider the record count alone sufficient to explain a ~1 minute load time.