REST offset pagination versus GraphQL cursor pagination for large Mattermost datasets

Goal

Paginate a large Mattermost dataset through the public API while avoiding the performance degradation that offset-based queries can exhibit as page numbers increase.

Constraint

Mattermost REST API v4 list endpoints typically expose page and per_page parameters, but offset-based pagination scans and discards earlier rows as the offset grows. The GraphQL API provides cursor-based first/last and before/after arguments on some connections, yet cursor support is not uniform across entities or releases. Direct database keyset pagination avoids offset cost but bypasses application-layer access controls and audit behavior.

Decision

Assuming Mattermost Server REST API v4 and an integration that cannot rely on arbitrary page jumps, which approach should be used when GraphQL coverage is incomplete: REST offset pagination with bounded page sizes, GraphQL cursor pagination where available, or direct database keyset pagination with entitlements enforced outside the API?

Verification against a running server is required because defaults and maximums differ by deployment.

• Should the integration prefer REST offset pagination with a capped per_page, or GraphQL cursor pagination where the schema supports it?
• Is direct database keyset pagination acceptable when GraphQL cursor support is missing, provided access controls are enforced separately?
• What handling is appropriate for per_page maximums that vary across Mattermost releases and System Console settings?