RoxiHaidi

I like that the diagram expands the JSONB structure. Does it still show the nested JSONB fields when the table has relationships or joins with other tables?

Nice info, suppose you are a woman like me, based on the colors....keep going!

Yeah, they need to use a different approach.

Absolutely, that's a very practical approach to take. In reality, the optimal solution for databases doesn't necessarily match what people would select right now from scratch.

If a system is working fine, the expense and risk of moving may end up being far greater than any optimization efforts on the existing database. This is also why I believe profiling tools, explain plans, and indexes are all useful; there are plenty of cases where MongoDB is sufficient but still needs optimization...

That's a valid concern. I completely understand that compound indexes should not be applied blindly, and the database should select an appropriate execution plan on its own.

That's also why I decided to concentrate on the entire workflow rather than on the index itself in the article: Find the slow query -> Analyze Explain -> Analyze the ratio between scanned and returned documents -> Create an index -> Test the same query again...

In this particular case, a compound index was selected based on filters and a sort clause. I completely agree that using index intersections in a real workload could be quite dangerous, especially if MongoDB chooses to use another index instead.

The `$addToSet` example is also very valid; however, for me, that is more like a schema problem than a regular indexing problem in a read query. Still, the array could become extremely big regardless of the presence of indexes, and it might require a dedicated note in the article.

wow, that's very interesting and super useful!