We want to support deployments with hundreds of users by the end of the year. Many of our current views do not support this kind of scale.

• Paginate Workspaces page
• Paginate Users page
• audit: filtering can lead to confusing results because pagination state is kept #4518
• Only support pagination on resource lists with a search present
• Do not force pagination so API/CLI usage is not paginated (e.g. optional query params)
• make it mobile friendly (maybe only prev, current, next)
• pagination: pager shows multiple pages when filter returns no results #5092
• refactor all pagination (Users, Workspaces, and Audit Log) to use window functions so that there is one endpoint and one SQL query per paginated feature

We can leave the Templates page as is. We assume the number of templates will grow logarithmically with the number of users.

In the future we may want to paginate:

• Groups page
  • users within groups
• Build log
  But they're not a priority now.

We'll follow the pattern of pagination used in the Audit Log - limit/offset style pagination, with controls allowing the user to go forward, back, or to a specific page.

We will not apply pagination to the CLI because losing an entry due to the limit/offset style could be problematic there.

Each page needs both the item fetching to be paginated and a count endpoint. They're separate endpoints so that the count one can be called less frequently, as it's more expensive.