Before designing MongoDB data models, unlearn relational habits and re-think how you analyze data needs

When you’ve worked with relational databases for years, certain instincts become second nature: 

• Normalize the data 
• Remove duplication 
• Enforce relationships with foreign keys 
• Query everything back with joins 

It’s clean. It’s structured. It’s logical. And for many problems, it’s still the best way to think. 

But the moment we step into MongoDB (or any document database), those familiar instincts don’t map cleanly anymore. What used to feel “right” in MySQL can actually produce rigid, slow, or over-engineered designs in MongoDB. 

Let’s break down why this mindset clash happens —and why it’s not a MongoDB problem but a mental model problem. 

The Habit: “Split data into separate tables”

In relational thinking, we naturally break entities apart: 

• orders 
• order_items 
• products 
• addresses 

This is good relational design. It minimizes redundancy and gives us flexibility to query data in many different ways. When the UI needs everything together, we simply join and fetch it. 

But in MongoDB, that same structure can be a trap. 

Why it clashes: 
Document databases reward data locality — meaning store together what you read together. 

In the real world, when a user opens an Order Details page, they want: 

• Order info 

• Line items 

• Product names 

• Shipping details 

If you model everything in separate collections (like a relational schema), then for a single page view, MongoDB has to: 

• Fetch order 

• Fetch order items 

• Fetch product details 

• Fetch address 

Now you’re either doing multiple round-trips in the application or using $lookup (which is just a slower, poorer cousin of a JOIN). In other words: you brought relational thinking into a document world and then got frustrated that it “performs worse.” 

The Habit: “Joins will save us”

In MySQL, joins are a superpower. They allow flexibility: 

”I can always reconstruct any view of the data later.” 

This mindset is great for analytics, reporting, and complex querying. 

But in MongoDB: 

• There are no native joins 

• $lookup exists, but it’s not meant to be your daily hammer 

• The design goal is fewer queries, not more flexible joins 

Mindset shift: 
Relational DB: “Store minimally, reconstruct later.” 
Document DB: “Store for the access pattern, read in one go.” 

The goal is optimizing the common queries, not making every possible query easy. 

The Habit: “Schema = Structure”

In relational DBs, schema is the law. The database enforces structure. 

MongoDB flips this: 

• The application owns structure 

• The document can evolve 

• The schema can adapt over time 

For an RDBMS developer, this feels chaotic at first. But for evolving systems with frequently changing requirements, it becomes a superpower — if you embrace it intentionally instead of fearing it. 

Example: Order Details 

When 90% of the time your system is reading the whole order, MongoDB’s approach is actually the cleaner, faster, simpler one — but only after you let go of the normalization instinct. 

So What’s the Real Problem? 

The issue isn’t that MongoDB is “weird” or “less structured.” 
The issue is that most of us try to apply relational thinking in a non-relational world. 

MongoDB will make perfect sense if we first shift our mental model: 

Key Takeaways:

• MongoDB is not “MySQL with JSON syntax” 

• If you model MongoDB like a relational DB, it will perform worse 

• Document thinking requires us to optimize for read locality, not relational purity 

• The database design must start from how data is accessed, not how it relates 

This sets the foundation for the rest of the migration journey. Before touching data models, we must unlearn and relearn how to analyze data needs.