Why should you care?

When product attrs or custom tenant fields appear unpredictably, wildcard indexes support queries without constant index redesign — with trade-offs on write cost.

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.products.insertOne({
  name: "Camera",
  specs: { megapixels: 24, weatherSealed: true, mount: "E" }
})
db.products.createIndex({ "specs.$**": 1 })
db.products.find({ "specs.megapixels": { $gte: 20 } })

Run Example »

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

What happened?

• specs.$** indexes all subfields under specs.
• The find on megapixels can use the wildcard index.
• You still prefer normal indexes for the hottest known fields.

Practice next

1. Insert a product with nested specs.
2. Create the wildcard index.
3. Query different specs paths.
4. Wildcard index customFields.$** on tenants.
5. Combine with a regular index on name.

Remember

Wildcard indexes cover unknown subfields. Helpful for flexible specs. Use sparingly — writes get heavier.

Tenant-defined custom fields

Each enterprise customer adds different CRM fields under custom.

Outcome: Support can still filter on those paths without per-tenant indexes.