Вы подняли очень интересную тему - как эффективно сделать pagination. Готовых решений, которые сходу вас устроят, тут нет. Но есть большой опыт, накопленный при решении этих проблем, который можно перенимать. Ищите по ключевому слову "pagination".
Дам вам несколько точек старта:
1) Можно не закрывать коннекшн, и по мере поступления запросов двигаться дальше в курсоре. Реализуется достаточно просто, но совершенно не масштабируется. На каждого юзера у вас будет одно долгоживущее соединение. Если у вас 10-20 юзер, и их не будет больше - то можете смело идти этим путем.
2) Можно на каждый запрос новой "страницы" делать новый запрос на весь датасет, и просто проматывать его. Начинает себя хуже вести по мере роста количества записей. Тут надо смотреть, как ведут себя юзеры. Если смотрят только первые несколько страниц - то ничего страшного не будет. Если же они идут глубоко по страницам - то проблемы будут нарастать со временем.
3) Можно, например, выдавать юзерам информацию с некоторым лагом. То есть, у вас есть, например, одна таблица с актуальными данными, которая меняется. А в другой таблице у вас read-only данные, которые перекачиваются из первой таблицы, например, раз в час. Этим данным выставляются какие-то дополнительные атрибуты (например, порядковый номер), по которым потом можно очень быстро искать. Это очень производительный вариант, отлично подходит для критичных по времени отклика приложений, но за это вы платите дополнительным гемором по разработке, и дополнительными требованиями к месту для хранения.
4) Можно сделать pagination с нефиксированным размером страницы и плавающими параметрами запроса. Например, вы ограничиваете размер ответа сервера в 25 записей. Первая страница выдает вам 25 записей, потом вы смотрите на "имя" или "дату обновления" последней из возвращенных записей, меняете запрос, и снова возвращаете следующие 25 записей. В зависимости от условий, он может вам вернуть, скажем 14 записей. Тогда вы их отображаете, а потом через AJAX делаете еще один запрос, который "добьет" WEB-форму до нужного размера.
5) Можно делать prefetch, возможно даже адаптивный префетч. То есть, у вас работает приложение, и вы собираете метрики пользователей. Потом по этим метрикам вы строите прогноз, насколько глубоко они обычно ходят. Наконец, основываясь на этом прогнозе, когда у вас юзер открывает первую страницу, вы в бэкгрануде, подгружаете, например, еще 4 страницы, и сохраняете в сессию, так как метрики вам сказали, что в среднем юзеры идут на 2-3 страницы вглубь.

И это далеко не все идеи. Как видите, подходов к решению этой проблемы очень много. И конкретный совет тут дать очень тяжело, так как выбор подхода зависит от множества факторов, которые известны только вам.