MongoDB
Explica cómo los índices TTL eliminan documentos según fechas, qué retrasos y límites tienen y cuándo sirven para sesiones, eventos o datos temporales.
Un TTL index elimina documentos automáticamente después de que un campo de tipo Date supera una política de expiración. La eliminación la realiza un proceso interno periódico, por lo que es , no exacta al milisegundo.
db.sessions.createIndex(
{ expiresAt: 1 },
{ expireAfterSeconds: 0 }
);Cada documento define su instante de expiración:
{
_id: sessionId,
userId,
expiresAt: ISODate('2026-07-25T12:00:00Z')
}Datos temporales como sesiones, tokens, caches o eventos efímeros necesitan limpieza continua. Sin TTL, la aplicación debe ejecutar jobs, mantener checkpoints y gestionar borrados.
TTL simplifica la retención técnica cuando la única acción necesaria es eliminar eventualmente el documento.
{ expiresAt: 1 }
{ expireAfterSeconds: 0 }Cada documento expira según su fecha.
db.logs.createIndex(
{ createdAt: 1 },
{ expireAfterSeconds: 60 * 60 * 24 * 30 }
);Todos expiran treinta días después de createdAt.
MongoDB revisa periódicamente los índices TTL y elimina documentos vencidos. Puede existir retraso por:
Por eso una sesión debe considerarse inválida en la lógica de aplicación cuando expiresAt <= now, aunque el documento todavía exista.
TTL no debe ejecutar acciones de negocio como:
La eliminación no llama código de aplicación. Para workflows usa scheduler, queue o job idempotente. TTL puede limpiar el registro después.
El campo debe contener Date compatible o, en algunos diseños, un array de dates con semántica específica. Strings ISO no son fechas BSON:
{ expiresAt: '2026-07-25T12:00:00Z' }No expirará como Date. Schema validation debe proteger el tipo.
Una sesión puede renovarse:
db.sessions.updateOne(
{ _id: sessionId, userId },
{
$set: {
expiresAt: new Date(Date.now() + ttlMs)
}
}
);Existe una carrera entre renovación y monitor TTL si el documento ya está vencido. La aplicación debe tolerar que haya sido eliminado y crear una sesión nueva cuando corresponda.
No confíes únicamente en la existencia del documento:
const session = await sessions.findOne({
tokenHash,
expiresAt: { $gt: new Date() }
});El filtro aplica la regla inmediatamente. TTL solo limpia almacenamiento.
El delete generado se replica a secondaries. Una gran acumulación de documentos vencidos puede producir carga de deletes, oplog y lag.
Al reducir drásticamente expireAfterSeconds en una colección grande, muchos documentos pueden quedar vencidos al mismo tiempo. Planifica purga por batches antes del cambio.
Time series collections soportan políticas de expiración específicas. La configuración y capacidades dependen de versión. No asumas que un TTL normal y una time series se administran igual.
Versiones modernas soportan combinaciones específicas de TTL parcial en ciertos contextos. Debes confirmar versión, FCV y restricciones antes de usarlo. No documentes como universal una capacidad reciente.
TTL normalmente requiere un índice de un solo campo. No lo combines arbitrariamente con otros campos esperando expiración por compound.
Si también consultas por usuario y fecha, puede necesitarse otro índice:
{ userId: 1, expiresAt: 1 }El índice TTL y el índice de query cumplen responsabilidades distintas.
Los deletes TTL pueden aparecer en Change Streams como eliminaciones. No dependas de la puntualidad para disparar negocio. Además, el evento puede no contener el documento completo sin opciones adicionales.
Documentos expirados pueden permanecer en backups creados antes del delete. La política de privacidad y retención debe contemplar backups y restores.
Restaurar un backup puede reintroducir documentos ya vencidos; el monitor los eliminará posteriormente, pero la aplicación debe filtrar por fecha desde el primer momento.
El documento no expira por ese índice.
No cumple la semántica esperada.
Puede persistir brevemente antes de ser eliminado.
La fecha enviada por clientes no confiables puede extender o acortar retención. Calcula expiración en una capa confiable.
Genera tormenta de deletes.
Puede desaparecer antes del update.
TTL es eventual.
No expira correctamente.
No ejecuta lógica ni garantiza evento puntual.
Satura el cluster.
Acepta documentos lógicamente vencidos.
Backups conservan versiones anteriores.
TTL es una política de limpieza eventual basada en fechas BSON. Reduce mantenimiento para datos efímeros, pero no reemplaza validación de expiración, scheduler, eventos de dominio ni políticas de backup. Su impacto operacional crece cuando muchos documentos vencen juntos.
expiresAt?Text search y Atlas Search.