An index, or a full collection scan

A query with no usable index reads every document in the collection and throws away the ones that do not match. On two hundred rows in development that is instantaneous; on two million in production it is a timeout, and the code did not change. This is the single most common reason a service that was fine last month is not fine today.

Compound indexes have an order and the order is the whole thing. An index on { tenantId: 1, createdAt: -1 } serves a query filtering by tenant and sorting by date, and also serves a query filtering by tenant alone, because a prefix of the index is still an index. It does nothing for a query on createdAt alone. Equality fields first, then the sort field, then ranges: that ordering rule covers most of what you need.

Indexes are not free. Each one is a structure that must be updated on every insert, update and delete, and each one occupies memory you would rather spend on documents. Six carefully chosen indexes beat twenty speculative ones, and an index nobody's query uses is pure cost. Check what is actually being used before you add another.