0Pricing
MongoDB Academy · Lección

Paginación por conjunto de claves con consultas de rango

Creará una paginación basada en cursores mediante un filtro de rango sobre _id o un campo de marca de tiempo, logrando un rendimiento constante de O(log n) por página.

Paginación por conjunto de claves con consultas de rango es una lección gratuita de MongoDB Academy en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de MongoDB Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de MongoDB Academy incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

What Is Keyset Pagination?

Keyset pagination—also called cursor pagination—avoids skip() entirely by using a range query on the sort key. Instead of telling MongoDB 'jump over the first N documents', you tell it 'give me documents where the sort key is greater than the last value I saw'. This is always O(log n) because it uses an index range scan, regardless of how far into the result set you are.

The Core Concept: A Range Filter as a Cursor

After fetching the first page, you remember the sort key value of the last document returned. For the next page, you filter documents where the sort key is strictly greater than (or less than, for descending) that remembered value. This filter combined with an index gives MongoDB an exact starting point—no skipping needed.

// First page — no cursor needed
const page1 = await db.collection('posts')
  .find({ isPublished: true })
  .sort({ createdAt: -1, _id: -1 })
  .limit(20)
  .toArray();

// Remember the last document's sort keys
const lastCreatedAt = page1[page1.length - 1].createdAt;
const lastId        = page1[page1.length - 1]._id;

Fetching the Next Page With a Range Query

Use the remembered sort key values in a $lt (or $gt for ascending) condition for the next page query. No skip() is needed—the range condition navigates the index directly to the right starting position. MongoDB fetches limit documents starting from that point.

// Next page: posts older than the last one seen
// Descending by createdAt means 'older' = $lt
const page2 = await db.collection('posts')
  .find({
    isPublished: true,
    $or: [
      { createdAt: { $lt: lastCreatedAt } },
      { createdAt: lastCreatedAt, _id: { $lt: lastId } }  // tiebreaker
    ]
  })
  .sort({ createdAt: -1, _id: -1 })
  .limit(20)
  .toArray();

Why Include _id as a Tiebreaker?

Multiple documents may have the same createdAt timestamp (e.g., many items inserted in the same second). Without a tiebreaker, the range boundary is ambiguous and you might skip or duplicate documents at the boundary. Adding _id as a secondary sort field and including it in the range condition makes the cursor uniquely deterministic—no document can have the same (createdAt, _id) pair.

// Compound index to support the keyset query
db.posts.createIndex({ createdAt: -1, _id: -1 });
// This index covers both the sort and the range filter

Keyset Pagination on _id Alone

If you sort purely by _id (default insertion order), keyset pagination is the simplest possible form. _id is always unique and already indexed. Each page returns documents where _id is greater than the last seen value. This works perfectly for feed-style queries where insertion order is the natural sort.

// First page
const page1 = await db.collection('events')
  .find({})
  .sort({ _id: 1 })
  .limit(50)
  .toArray();

const lastId = page1[page1.length - 1]._id;

// Next page — range filter on _id
const page2 = await db.collection('events')
  .find({ _id: { $gt: lastId } })
  .sort({ _id: 1 })
  .limit(50)
  .toArray();

Encoding the Cursor for API Responses

API clients should not need to know the internal cursor format. Encode the cursor as a Base64 or JWT string that the server can decode on the next request. This hides the implementation detail (whether you use createdAt, _id, or a composite key) from clients and lets you change the cursor format without breaking the API contract.

// Encode cursor
function encodeCursor(doc) {
  return Buffer.from(JSON.stringify({ createdAt: doc.createdAt, _id: doc._id })).toString('base64');
}

// Decode cursor
function decodeCursor(token) {
  return JSON.parse(Buffer.from(token, 'base64').toString('utf-8'));
}

// API response
const nextCursor = page.length === PAGE_SIZE ? encodeCursor(page[page.length - 1]) : null;
res.json({ data: page, nextCursor });

Keyset Pagination in an Express Handler

A complete keyset pagination handler decodes the incoming cursor (if provided), builds the range filter, runs the query, encodes the next cursor, and returns the response. If there is no next cursor to return (the page is smaller than the page size), the client knows it has reached the last page.

async function listPosts(req, res) {
  const limit = 20;
  let filter = { isPublished: true };

  if (req.query.cursor) {
    const { createdAt, _id } = decodeCursor(req.query.cursor);
    filter['$or'] = [
      { createdAt: { $lt: new Date(createdAt) } },
      { createdAt: new Date(createdAt), _id: { $lt: _id } }
    ];
  }

  const posts = await Post.find(filter).sort({ createdAt: -1, _id: -1 }).limit(limit).lean();
  const nextCursor = posts.length === limit ? encodeCursor(posts[posts.length - 1]) : null;

  res.json({ data: posts, nextCursor });
}

Keyset vs Offset: Performance Comparison

Imagine a collection with 1,000,000 posts. Offset pagination to page 1000 (20 items/page) executes skip(19980)—MongoDB walks 19,980 index entries. Keyset pagination uses a range filter: { createdAt: { $lt: someDate } }—MongoDB does a binary search on the index to find the starting point and scans exactly 20 entries. The difference at scale: milliseconds vs seconds.

Limitations of Keyset Pagination

Keyset pagination has two notable limitations: (1) you cannot jump to an arbitrary page number—you can only go forward or backward one page at a time; (2) the sort field must be part of the cursor, so sorting by non-unique, non-indexed fields requires careful tiebreaker selection. These trade-offs make keyset pagination unsuitable for applications that require page-number navigation, but it is the correct choice for infinite scroll and API cursor patterns.

Bidirectional Keyset Pagination

To support both 'next page' and 'previous page' navigation, store both the cursor for the first document and the cursor for the last document on each page. Use $gt with the first document's cursor to go backward. Reverse the sort direction for the backward query, then re-reverse the results before returning them.

// Previous page — documents newer than the first item on the current page
const prevPage = await db.collection('posts')
  .find({
    isPublished: true,
    createdAt: { $gt: firstDocCreatedAt }
  })
  .sort({ createdAt: 1, _id: 1 })  // reverse sort for previous page
  .limit(20)
  .toArray();

prevPage.reverse(); // flip back to descending display order

Index Design for Keyset Pagination

The compound index for a keyset pagination query should include: filter fields first (equality conditions), then the sort fields. For example, if you filter by isPublished and sort by createdAt DESC, _id DESC, the ideal index is { isPublished: 1, createdAt: -1, _id: -1 }. This index covers the equality filter and the range sort without any in-memory operations.

// Ideal covering index for keyset pagination on posts
db.posts.createIndex({ isPublished: 1, createdAt: -1, _id: -1 });

// Verify with explain — expect IXSCAN, no SORT stage
db.posts.find({ isPublished: true, createdAt: { $lt: new Date() } })
  .sort({ createdAt: -1, _id: -1 })
  .limit(20)
  .explain('executionStats');

Quick Check

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

Lesson Recap

In this lesson you learned: keyset pagination uses a range filter on the last seen sort key instead of skip(), this achieves O(log n) performance regardless of page depth, and including _id as a tiebreaker prevents duplicate or missing documents at sort boundaries. Next up we practice combining sort, skip, limit, and projections into a complete query chain.

Preguntas frecuentes

¿La lección «Paginación por conjunto de claves con consultas de rango» es gratis?

Sí — el texto completo de «Paginación por conjunto de claves con consultas de rango» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de MongoDB Academy, actualiza a CoddyKit PRO. El curso de MongoDB Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Paginación por conjunto de claves con consultas de rango»?

Creará una paginación basada en cursores mediante un filtro de rango sobre _id o un campo de marca de tiempo, logrando un rendimiento constante de O(log n) por página. Practicas MongoDB Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar MongoDB Academy?

No se requiere experiencia previa. MongoDB Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.

¿Cuánto tiempo toma la lección «Paginación por conjunto de claves con consultas de rango»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de MongoDB Academy?

Sí. Cada lección de MongoDB Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Ordenación con sort() y varias claves
  2. Skip y limit: paginación por desplazamiento
  3. Paginación por conjunto de claves con consultas de rango
  4. Combinación de sort, skip, limit y proyecciones
← Volver a MongoDB Academy