MySQL + MongoDB Together: The Real Cost of Polyglot Persistence

The common advice is: "pick one database and commit." It sounds like good advice because specializing in one tool is easier. But production workloads are so varied that one tool often isn't enough.

Our multiplayer game platform runs MySQL + MongoDB together. This post walks through why, how, and what that decision actually cost us.

Which data lives where?

Lives in MySQL

• User accounts — ID, email, hashed password
• Financial transactions — transfers, balances, payment history
• Tightly relational structures — tournaments, tables, sessions
• Reporting source — BI team writes SQL against it

MySQL's strengths: transactions (ACID), referential integrity, mature operational tooling (backup, replication, point-in-time recovery).

Lives in MongoDB

• Game state — real-time session state per user, lots of nested fields
• Player profile extras — avatar, preferences, settings (schemaless, varying)
• Event log — gameplay events, denormalized records

MongoDB's strengths: flexible schema, fast writes, nested document storage.

Why both?

Short answer: neither does everything well.

Storing game state in MySQL — five to six levels of nesting, schema migration on every change — painful.

Managing financial transactions in MongoDB — weak transaction guarantees, no JOINs — dangerous. A "₺10 transfer" that partially fails creates data inconsistency that's much more likely here than in MySQL.

Running both at the same time lets each handle what it's best at. The tradeoff is dual maintenance.

What does it actually cost?

1. Operational load doubles

Each DB requires:

• Backup strategy
• Monitoring
• Upgrade patterns
• Performance tuning
• Schema/index management

We use managed services (AWS RDS MySQL + DocumentDB for MongoDB) which reduces this, but doesn't eliminate it. It's "two systems you have to keep watching," even if each needs less work.

2. Developer mental-model confusion

The first question on any new feature: "Which DB should this data live in?" Sounds simple but it's always a conversation. Criteria:

• Relational? → MySQL
• Schemaless / variable fields? → MongoDB
• Transactional? → MySQL
• Write-heavy? → MongoDB usually wins
• Need relational queries? → MySQL

Every senior knows this; teaching a junior takes time.

3. Data consistency splits across tools

When you store half-related data across two DBs — say user profile in MySQL, game state in MongoDB — updating one and then the other creates an eventual consistency problem.

Fix: define domain boundaries cleanly. A given field lives in only one DB. Cross-references are IDs (not foreign keys — joined in the app layer).

4. Backup/restore coordination

In an incident, "restore the database to last night" might not be enough with just MySQL — you may need MongoDB restored to the same timestamp. Time-aligned restore across two systems is a complex operation.

Four questions before adopting polyglot

Before I'd add any second DB, I'd ask:

1. Is a feature of the current DB genuinely limiting you?

• If the existing MySQL works fine and you're adding MongoDB because "it's more modern" — stop. MongoDB isn't the answer to that problem.

2. Can the team actually manage both operationally?

• Big enough team? Is someone actively responsible, or is it "someone handles it as they have time"? Separate monitoring for each?
• If the answer is "one person will handle it," the answer is wrong.

3. Is consistency across the two DBs important?

• "It's flexible" means it's not important.
• "No, it can't be out of sync" means those two pieces of data must live in the same DB. Otherwise you're building a bug factory.

4. What's the migration cost?

• Adding a second DB for "one small feature" is short-term gain, long-term pain.
• A strategic architectural decision? Then yes.

My practical recommendation

Start with one DB. Run with it for years. When you realize the current DB is genuinely limiting you, add the second — and define the second DB's role precisely.

"From now on, data of type X lives in MongoDB." Draw the line. Don't drift random data across.

Without that discipline, polyglot persistence becomes "everything anywhere" chaos. When that happens, the team gets confused, incidents get harder, onboarding eats 3 weeks.

Takeaway

Polyglot persistence is a good tool when applied at the right time with a clear boundary. Not "we have two DBs, look how modern." If you see real workload divergence, yes. If not, staying with one is always simpler.

Simple is preferred. If circumstances require, non-simple is preferred. That ordering is always right.