в силу специфики деплоймента нельзя допустить обосрамс.

готовый продукт пакуется в rpm-ки, несется флешкой специальным человеком ногами в офис, там он проходит сканирование сетчатки, и разворачивает все это на специальном ноутбуке, подключенному к air-gapped системе, и забирает на флешку логи.

Блин сколько же вас сидит софтину пилят?

Да, уж. Ненавижу больше всего страх у разработчиков что-то менять.

Если обосрамс, то максимум 15 минут должно быть на исправление. Или откат макс за минуту.

не, обосрамс, если происходит, то происходит в более глубоком смысле, и просто откатить не получится, т.к. из-за, опять же, специфики у нас центральная база данных - append only

Если вы считаете количество записей одним запросом, затем делаете offset уже от этого числа, то вы с тем же успехом можете получить и первичный ключ последней записи одним запросом.

Количество записей зачастую и так надо на фронте показать.
А вот прорабатывать логику "сгенерировать курсор для 10 объекта с конца, для 20 объекта с конца и тд..." как-то неудобно. Плюс надо понимать в какой момент эти страницы могли уже пересечься. Плюс как рассчитать номера самих страниц, чтобы их вывести пользователю... В общем куча вопросов и без примеров сложновато.
С нашей командой фронтов и мобильных разрабов так и не нашли удобства в курсорах.

В принципе в этой статье https://use-the-index-luke.com/no-offset есть примеры использования подобных курсоров в фреймворках. Надо будет покурить примеры из них. Быстро пробежавшись не увидел решения для вывода курсоров к наборам страниц, а не бесконечных курсоров.

вам не нужно рассчитывать номера страниц - вы просто встраиваете их в курсор

блин а че делать когда ну очень нужно вычислять. Ну к примеру когда  SSR. белее 2 000 000 записей. На первых страницах при банальном skip все ок. А на последних «Выбрка. Ушла на базу вернусь не скоро». У меня пока монго. поменять не проблема