Why should you care?

Multi-tenant lists almost always filter tenantId + status and sort by time. One compound index can serve that entire pattern.

See it live — copy this example

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

db.orders.createIndex({ tenantId: 1, status: 1, createdAt: -1 })
db.orders.find({ tenantId: "acme", status: "open" }).sort({ createdAt: -1 }).limit(20)
db.orders.find({ tenantId: "acme", status: "open" }).explain("executionStats")

Run Example »

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

What happened?

• The index prefix tenantId + status matches the filter; createdAt: -1 supports the sort.
• explain should avoid an in-memory sort when the index fits.
• Queries that skip tenantId cannot use this index efficiently.

Practice next

1. Create the compound index.
2. Run the find+sort and check explain.
3. Query only { status: "open" } and see a worse plan.
4. Add customerId after tenantId for support views.
5. Compare with two separate single indexes — usually worse for this query.

Remember

Compound indexes serve multi-field filters + sorts. Order is Equality → Sort → Range. Prefixes of the index can still be used.

Tenant order inbox

B2B ops opens open orders newest first for their tenant.

Outcome: One IXSCAN returns the page without sorting in RAM.