If you're a backend developer working mostly in relational databases (Laravel + MySQL, in my case), it's easy to fall into one of two traps: either dismissing NoSQL entirely as "overhyped," or reaching for MongoDB because it feels modern. Neither is a good default.
Here's the practical way I think about it.
Default to MySQL. Reach for MongoDB only when you have a reason.
Relational databases give you referential integrity, real ACID transactions, and a mature query language for joins and aggregations. For most CRUD-heavy business applications — e-commerce, SaaS dashboards, anything involving payments or invoicing — that's exactly what you want. Don't give it up for the sake of using something new.
The 4 situations where MongoDB genuinely wins
1. The schema is variable or unknown ahead of time
Product catalogs where a laptop and a t-shirt have completely different attributes. Dynamic form builders. Event logs where every event type has different fields. Forcing this into rigid relational tables usually means either an EAV pattern (painful) or JSON columns bolted onto MySQL (a partial workaround, not a real solution).
// A document can just hold whatever shape it needs
$product = [
'name' => 'Laptop',
'specs' => ['ram' => '16GB', 'cpu' => 'i7']
];
// The next product's specs array can look nothing like this one
2. Your main read pattern is "give me the whole thing," not joins
If a typical query is "fetch this order with its items, shipping info, and a customer snapshot," that's 4-5 joins in MySQL. In MongoDB you can embed related data into a single document and read it in one round trip — faster for read-heavy, document-shaped access patterns.
3. Massive write throughput and horizontal scaling
Logs, IoT sensor streams, notification pipelines — anything writing millions of records where you need sharding to scale horizontally. MongoDB gives you that out of the box; sharding MySQL manually is a real engineering project.
4. Relationships are shallow or non-critical
If your data doesn't lean heavily on foreign keys and strict referential integrity, giving up strict ACID guarantees isn't a real cost.
Where MySQL still wins, even in the same project
- Strong relational data (users → orders → payments → invoices) needing real transactions
- Complex reporting with joins and aggregations — SQL is simply better at this
- Framework fit: if you're on Laravel, Eloquent relationships, migrations, and money-handling logic are built around relational thinking
The practical rule I use
MySQL stays the primary store. MongoDB gets used for a specific slice of the system — activity logs, a highly variable product catalog, or a cache-like layer — not as a replacement for the whole database layer. Polyglot persistence (using both in the same project, each for what it's good at) is usually the right answer, not picking one exclusively.
What's been your experience mixing MongoDB and a relational database in the same project? Curious what patterns worked (or didn't) for others.
Top comments (0)