MongoDB
Explica cómo lean evita hidratar documentos Mongoose, reduce memoria y CPU y qué funcionalidades se pierden al devolver objetos JavaScript simples.
Una query normal de Mongoose convierte cada resultado en un con métodos, getters, virtuals, change tracking y metadata interna. evita esa hidratación y devuelve objetos JavaScript simples.
lean()MongoDB result
→ hydration
→ Mongoose Document
MongoDB result
→ lean
→ plain objectLa mejora ocurre principalmente en CPU y memoria de Node.js. El plan de MongoDB, los índices y la cantidad de documentos examinados no cambian por usar lean.
const products = await Product.find({
businessId,
active: true
})
.select('name price stock')
.lean();El resultado no tiene .save(), métodos del schema ni change tracking.
Lean es apropiado para:
No aporta valor si después necesitas mutar y guardar mediante document methods.
Según configuración y versión, un lean result no incluye automáticamente:
save();isModified();toJSON.Plugins pueden reintroducir parte de este comportamiento, pero también coste y complejidad.
userSchema.virtual('fullName').get(function () {
return `${this.firstName} ${this.lastName}`;
});Con una query lean, fullName normalmente no existe salvo opciones o plugins compatibles. Para contratos públicos importantes, calcula el DTO explícitamente en lugar de depender de magia de hydration.
const orders = await Order.find({ businessId })
.populate({ path: 'customerId', select: 'name' })
.lean();Los documentos poblados también suelen ser lean. Esto reduce memoria, pero getters, virtuals y methods de los Models relacionados tampoco estarán disponibles.
La diferencia aumenta cuando:
Puede ser irrelevante cuando la query devuelve uno o dos documentos y el cuello está en un COLLSCAN o red.
Mide por separado:
Lean no sustituye una projection:
Product.find(filter)
.select('_id name price')
.lean();Traer un documento enorme como plain object sigue siendo costoso. Reduce campos y limita resultados.
El tipo de un lean result no es igual a un hydrated document. Evita reutilizar el mismo tipo para ambos.
type ProductListRow = {
_id: ObjectId;
name: string;
price: Decimal128;
};Después transforma a DTO:
const dto = {
id: row._id.toString(),
name: row.name,
price: row.price.toString()
};Un objeto lean puede modificarse en memoria, pero eso no persiste:
product.stock = 0;
// no existe product.save()Para escribir, ejecuta un update explícito con filtro de autorización y preconditions.
Hydration puede hacer que ciertos defaults parezcan presentes aunque el documento almacenado no los tenga. Lean revela más directamente lo persistido.
Esto es útil para detectar schema drift, pero puede romper código que asumía defaults. La solución correcta es lectura tolerante o migración, no quitar lean sin analizar.
Lean sigue devolviendo tipos BSON como ObjectId, Decimal128 y Date. No significa que el objeto esté listo para API pública. Usa mapper y no expongas campos internos.
Query middleware sí puede ejecutarse antes de obtener resultados; document middleware y métodos de documento no aplican. Un endpoint puede seguir teniendo efectos implícitos por query hooks aunque utilice lean.
Lean no protege secretos. Si la query incluye passwordHash, el objeto lo contiene. Usa select: false, projection explícita y DTO.
Tampoco reemplaza tenant filters ni autorización.
Plugins como lean virtuals o lean getters intentan recuperar comportamiento. Evalúa:
Si terminas reconstruyendo toda la hidratación con plugins, quizá lean ya no aporta el beneficio esperado.
Compara en un escenario representativo:
No compares resultados con campos distintos.
.save();lean() elimina hidratación y reduce trabajo en Node.js, no en MongoDB. Es ideal para lecturas que solo proyectan y serializan. Debes aceptar la pérdida de methods, getters y virtuals, modelar tipos separados y seguir usando projections, autorización y DTOs.
Repositories y acceso a datos.