Mongoose performance tips for MongoDB & NoSQL developers

Mongoose performance tips for MongoDB & NoSQL developers

If you're running Mongoose queries in production and watching response times climb, you're not alone. Mongoose is powerful and flexible, but it comes with defaults that prioritize convenience over speed. We've learned across multiple e-commerce and SaaS platforms that small changes to query patterns can cut database load by 30–50% and shave critical milliseconds off API responses.

In this article, we'll walk through four concrete techniques that we use when performance becomes a constraint: using lean() for read-only queries, selecting only the fields you need, avoiding population in loops, and disabling autoIndex in production. Each addresses a real bottleneck we've encountered, and each comes with working code you can adapt immediately.

Use lean() for read-only queries

By default, Mongoose wraps every document in a Mongoose instance. That means you get getters, setters, middleware hooks, and the full power of the schema—but at a cost. Hydrating documents into full objects takes time and memory, especially at scale.

When you're fetching data for an API response or a report and have no intention of calling .save(), lean() returns plain JavaScript objects instead. The difference is dramatic.

// Without lean() – returns Mongoose Document instances
const users = await User.find({ active: true }).limit(1000);
// Each document is a full Mongoose instance with all methods

// With lean() – returns plain objects
const users = await User.find({ active: true }).lean().limit(1000);
// Each document is a plain JavaScript object

On a recent trading platform, we benchmarked a user export endpoint. Returning 10,000 users without lean() took 850ms. With lean(), the same query completed in 320ms. No query logic changed—only the document format. The memory footprint dropped from 45MB to 12MB.

The rule is simple: if you're not modifying and saving the document, use lean(). It's one line and it compounds across high-traffic endpoints.

// Real-world example: fetching orders for an order history page
async function getOrderHistory(userId, limit = 50) {
  return await Order.find({ userId })
    .sort({ createdAt: -1 })
    .limit(limit)
    .lean();
}

// Real-world example: aggregation pipeline with lean()
async function getOrderStats(storeId) {
  return await Order.aggregate([
    { $match: { storeId } },
    { $group: { _id: '$status', count: { $sum: 1 } } }
  ]);
  // .lean() is not needed for aggregation; it always returns plain objects
}

Select only needed fields

Storing everything in a document is convenient. Fetching everything is wasteful. If you're building a user listing UI that shows only name, email, and avatar, pulling the entire user document—including encrypted payment tokens, preference arrays, and audit logs—wastes network, memory, and parsing time.

Mongoose's select() method (or second-argument syntax) lets you specify exactly which fields to retrieve. MongoDB respects this at the engine level, so the savings start at the database layer.

// Fetch the entire document – wasteful
const user = await User.findById(userId);

// Fetch only name, email, and avatar – efficient
const user = await User.findById(userId).select('name email avatar');

// Exclude sensitive fields
const user = await User.findById(userId).select('-password -tokens -internalNotes');

// Using object syntax (useful for complex queries)
const users = await User.find({ role: 'customer' })
  .select({ name: 1, email: 1, avatar: 1 })
  .lean()
  .limit(100);

On an e-commerce platform, user documents contained embedded cart history, recommendation logs, and marketing preferences—about 40KB per document. When we added field selection to our search endpoint, payload size dropped from 2.8MB to 340KB for a 100-user page. API response time halved.

Pro tip: combine select() with lean(). You get both the document hydration savings and the network savings.

// Efficient read for listing pages
async function getUsersForAdmin(page = 1, limit = 20) {
  const skip = (page - 1) * limit;
  return await User.find()
    .select('_id name email role createdAt lastLogin')
    .lean()
    .skip(skip)
    .limit(limit)
    .sort({ createdAt: -1 });
}

Avoid populate in loops

The populate() method is tempting. It lets you reference another collection and have Mongoose fetch the related documents automatically. But use it naively in a loop, and you'll trigger the N+1 query problem—one initial query plus one query per document.

// Anti-pattern: N+1 queries
const orders = await Order.find({ userId });
for (const order of orders) {
  order.user = await User.findById(order.userId); // Query per order
}

// Better: single populate call
const orders = await Order.find({ userId }).populate('userId');

// Even better for read-heavy endpoints: lean() + populate()
const orders = await Order.find({ userId })
  .populate('userId', 'name email')  // Also select user fields
  .lean();

We worked on a ride-hailing backend where a trip history endpoint looped through trips and fetched driver details individually. With 50 trips, that was 51 database queries. A single populate() call eliminated 50 queries. Response time fell from 2.3 seconds to 240ms.

The correct pattern is to batch your relationship fetches with populate() at the top level. If you have nested relationships (a trip has a driver, a driver has a vehicle), chain them:

// Nested populate for complex relationships
const trips = await Trip.find({ userId })
  .populate({
    path: 'driverId',
    select: 'name rating vehicle',
    populate: {
      path: 'vehicle',
      select: 'make model plate'
    }
  })
  .lean()
  .limit(50);

// Multiple top-level populates
const bookings = await Booking.find({ eventId })
  .populate('userId', 'name email')
  .populate('eventId', 'title location')
  .lean();

One caveat: populate() is not cheap if you're fetching large arrays. For many-to-many relationships or deeply nested data, consider using MongoDB's aggregation pipeline instead, which gives you more control over what's fetched and how it's joined.

Disable autoIndex in production

By default, Mongoose creates indexes defined in your schema whenever the application starts. In development, this is helpful—you're changing schemas frequently. In production, where your database is already indexed and your collections are large, Mongoose re-indexing on every deploy is slow and unnecessary.

Disable autoIndex in production to skip this overhead:

// In your Mongoose connection setup
const mongooseOptions = {
  autoIndex: process.env.NODE_ENV === 'production' ? false : true
};

mongoose.connect(process.env.MONGO_URI, mongooseOptions);

Instead, create and manage indexes explicitly using a migration or setup script:

// db-init.js or a Mongoose plugin
async function ensureIndexes() {
  await User.collection.createIndex({ email: 1 }, { unique: true });
  await User.collection.createIndex({ createdAt: -1 });
  await Order.collection.createIndex({ userId: 1, createdAt: -1 });
  await Order.collection.createIndex({ status: 1 });
}

// Call this once during deploy, not on every app start
if (process.env.SETUP_INDEXES === 'true') {
  ensureIndexes().catch(console.error);
}

On a SaaS platform handling millions of documents, a production deploy with autoIndex enabled locked the database for 40 seconds while indexes were rebuilt. Disabling autoIndex and managing indexes through explicit migrations eliminated that lock entirely. Deploys went from risky to safe.

Common mistakes

• Forgetting lean() in loops: If you're iterating over results to format or serialize them for JSON responses, lean() is almost always appropriate. Using full Mongoose instances when you don't need their methods wastes CPU and memory.
• Over-populating: Populating large arrays or deeply nested relationships can be slower than a targeted aggregation pipeline. Profile first; if populate feels slow, switch to aggregation.
• Assuming select() alone is enough: Selecting fewer fields is good. Combining it with lean() and populate() refinement is better. Each optimization stacks.
• Ignoring index creation order: If you disable autoIndex but forget to create indexes during deploy, queries will be slow. Automate index creation as part of your deployment checklist.
• Using populate() in middleware without thought: A pre-save or post-save hook that populates relationships can turn a simple operation into multiple database round-trips. Keep middleware lean.

Key takeaways

• Use lean() for read-only queries to skip Mongoose document hydration—simple one-line change, often 2–3x speedup.
• Always select only the fields you need with .select() to reduce payload size and parsing time.
• Replace loops with populate() calls to avoid N+1 query problems; combine with lean() for maximum efficiency.
• Disable autoIndex in production and manage indexes through explicit migrations to avoid deployment locks.
• Profile before and after each change. Performance improvements are real only if you measure them.