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.
It looks interesting. I actually did this yesterday. I needed to upload PNG photos on Medium, because they do not accept WebP photos, but I used Greenshot to take the screenshots again. I'm gonna save this for later.
A small thing: I think the upload was pretty slow. maybe it's just my internet...