¿Cómo paginarías un endpoint de colección grande, y por qué no usar simplemente limit y offset?

Prefiere la paginación por clave, también llamada paginación por cursor: ordena por una clave única y estable, devuelve un cursor opaco de la última fila y consulta las filas posteriores. La paginación por offset obliga a la base de datos a leer y descartar cada fila saltada, así que la página cinco mil es lenta, y las filas insertadas o borradas mientras se navega provocan duplicados y huecos. La paginación por clave mantiene coste constante por página y es estable frente a escrituras.

Por defecto uso paginación por clave. El cliente pide una página, recibe elementos más un cursor opaco, y la siguiente petición dice dame las filas posteriores a este cursor. Por debajo eso es una cláusula where sobre la clave de orden, así que con el índice adecuado es una búsqueda por índice y el coste es el mismo en la página uno que en la mil. El offset no puede hacer eso, porque la base de datos sigue recorriendo y descartando todo lo anterior al offset y, peor todavía, si se inserta una fila mientras alguien navega, todas las páginas siguientes se desplazan y ve un duplicado o se salta un elemento entero. El detalle que pilla a la gente es el desempate: si ordeno por created at y dos filas comparten marca de tiempo, el orden no es determinista, así que el cursor codifica created at más el id y la comparación va sobre el par. Lo que pierdo son los saltos arbitrarios de página y los conteos totales baratos. En un feed de scroll infinito nadie los echa de menos; para una tabla de administración que necesita números de página usaré offset con un máximo acotado.