Why should you care?

A global SaaS with millions of tenants will fail if every query forgets tenantId or scans unbounded collections.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// Access-pattern first: tenant + status + recent
db.orders.createIndex({ tenantId: 1, status: 1, placedAt: -1 })
db.orders.find(
  { tenantId: "acme", status: "open", placedAt: { $gte: ISODate("2026-07-01") } },
  { total: 1, placedAt: 1, items: { $slice: 5 } }
).sort({ placedAt: -1 }).limit(50)

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• The compound index matches the filter and sort.
• Projection returns only needed fields and slices items.
• tenantId is mandatory.
• limit bounds work.

Practice next

1. List your top 5 read APIs and their filter fields.
2. Create one compound index per hot pattern.
3. Add tenantId (or userId) to every filter.
4. Add customerId into the index for a support view.
5. Replace $slice with a lighter line-count field.

Remember

Design indexes from real queries. Always scope by tenant/user. Bound results with limit and projection.

Multi-tenant order console

Ops users at a B2B platform only query their tenantId; indexes enforce speed and isolation.

Outcome: Console stays under 100ms even with millions of orders globally.