Лента с бесконечной прокруткой использует LIMIT 20 OFFSET N. С ростом N страницы отдаются всё медленнее, а пользователи жалуются на дубли. В чём причина и что делать?

Два независимых дефекта OFFSET:

• производительность — OFFSET 100000 LIMIT 20 читает 100 020 строк по индексу и выбрасывает 100 000. Индекс не спасает: строки всё равно нужно пройти. Глубокие страницы (и боты, которые до них доходят) нагружают базу;
• корректность — пока пользователь листает, в начало ленты добавляются записи. Окно сдвигается: следующая страница начинается с элементов, которые уже были показаны (дубли), а при удалениях — элементы пропускаются.

Keyset-пагинация запоминает позицию последнего показанного элемента и просит следующие после неё. С составным индексом (created_at, id) база находит позицию за O(log n) и читает ровно 20 строк — на любой глубине. Вставки в начало не влияют: «после элемента X» не зависит от того, сколько элементов появилось перед ним.

Детали:

• ключ сортировки должен быть уникальным — иначе при одинаковом времени элементы теряются или дублируются; добавляют id;
• сравнение кортежей (a, b) < (x, y) поддерживается в PostgreSQL и использует составной индекс;
• курсор кодируют в непрозрачную строку (base64 от значений), чтобы клиент не зависел от формата и его можно было менять;
• направление «назад» — обратный порядок и разворот результата.

Когда OFFSET допустим: маленькие таблицы, админки с переходом на номер страницы, где точность не важна, или при ограничении глубины.