
Another New Year. Another reset. Another wave of optimism!
Or, if you are a fan of Manchester United (like me), maybe not so optimistic.
You’ve seen this pattern before. A bad run of form forces a big change:
- Sack the manager
- Bring in a new system
- Promise a fresh start
And yet … the same mistakes keep happening. Poor spacing. Slow transitions. Players doing too much because the fundamentals aren’t there.
Your database systems fail in exactly the same way.
Most MongoDB Problems Aren’t Tactical
Nearly all database problems aren’t tactical, they are Fundamental.
When a MongoDB query is slow, teams often reach for drastic solutions:
- Redesign the schema
- Rewrite the aggregation
- Add caching
- Introduce another service
That’s the database equivalent of firing the coach mid-season.
Sometimes it’s justified. Most of the time, it isn’t.
What actually fixes performance are the boring fundamentals:
- Making sure to
$matchearly, before$groupor$lookup - Using
$projectto avoid away fields you don’t need - Creating indexes that match real query patterns, not guesses
- Removing indexes that look useful but actually never get used
None of these moves make headlines. All of them win games (or in this case just perform better).
MongoDB Doesn’t Care Who the Manager Is
MongoDB executes exactly what you put on the pitch:
- A late
$matchcauses scans of documents unnecessarily - A large document still consumes too much memory
- A
$lookup(without proper filtering) still explodes the result set
There’s no “new manager bounce” in MongoDB. Good intentions don’t automatically get optimized away.
That’s frustrating, but it’s also why MongoDB is so reliable. When you fix something small and concrete, the improvement is real, measurable, and repeatable.
You Can’t Press If Your Shape Is Wrong
Football (soccer) teams that struggle often press harder, instead of fixing spacing.
Teams using MongoDB sometimes do the same:
- Overloading documents, instead of spreading out the data
- Adding caching, instead of fixing query shape
- Scaling hardware instead of fixing indexes
- Rewriting code instead of understanding the execution plan
Instead, take a page from the playbook of the best coaches in the world: Performance almost always starts with structure:
- Smarter shape (are you using the best data modeling principles? )
- Fewer documents flowing through each stage
- Fewer fields carried forward
- Fewer assumptions about what the database “should” optimize, improve your indexing
Get the shape right, and everything downstream improves.
A Better New Year’s Resolution (for MongoDB and Football Fans)
Instead of promising a rewrite this year, try this:
Fix one small MongoDB mistake you can measure.
One slow query.
One bloated pipeline.
One misleading index.
MongoDB rewards consistency and fundamentals, even when your football team keeps searching for the next big reset.
Progress isn’t always dramatic. Sometimes it’s just fewer self-inflicted problems.
Next Steps and Resources
So what are you waiting for, go make a difference in this new year … one small change at a time!
MongoDB Badges
These are super short, fun ways to learn about a MongoDB topic and you’ll get a badge when you complete them!
- Relational to Document Model
- Schema Design Patterns and Anti-patterns
- Advanced Schema Design Patterns and Anti-patterns
- Schema Design Optimization
- Indexing Design Fundamentals
- Performance Tools and Techniques
Learning MongoDB Course
You can also checkout a free lesson on indexes from my MongoDB Course on LinkedIn Learning:
Basic indexes from Learning MongoDB by Justin Jenkins
MongoDB University
And as always keep an eye out here for more MongoDB learning content, Happy New Year!

