Polyglot Persistence
debt(d8/e8/b8/t6)
Closest to 'silent in production until users hit it' (d8) — wrong-store choices (MySQL LIKE for full-text, BLOBs in DB) don't trip phpstan or deptrac; they surface as production performance degradation. Slightly better than d9 because slow query logs / APM can flag the symptom.
Closest to 'architectural rework' (e8) — introducing or removing a datastore requires data migration, new client libraries, ops tooling, backup strategy, and code changes across repositories/services. Not a quick_fix despite the cheery summary; the swap itself is multi-component architectural work.
Closest to 'strong gravitational pull' (b8) — each additional store applies across web and cli contexts, shapes deployment, monitoring, transactions (no cross-DB ACID), and team expertise. Slightly above b7 because operational complexity compounds, but not b9 since individual stores can be removed.
Closest to 'serious trap' (t6) — misconception explicitly says 'more databases ≠ better architecture'; devs adding a store per feature ignore operational compounding and impossibility of cross-database transactions. Contradicts the intuitive 'right tool for the job' framing.
Also Known As
TL;DR
Explanation
Different data types have different optimal storage characteristics: relational data (users, orders) fits PostgreSQL; session/cache fits Redis; search fits Elasticsearch; document data fits MongoDB; time-series metrics fit InfluxDB or TimescaleDB; graph relationships fit Neo4j. Polyglot persistence picks the best tool for each use case. The challenge: operational overhead of maintaining multiple systems, consistency across systems, and transaction management across boundaries. Best applied incrementally when a clear mismatch with the current store exists.
Common Misconception
Why It Matters
Common Mistakes
- Adding a new database for every new feature — operational complexity compounds quickly.
- Cross-database transactions — they are impossible without careful application-level sagas.
- Not considering team expertise — a MongoDB cluster maintained by a team unfamiliar with it is dangerous.
- Premature polyglot — solve the problem with your existing store first, add a new one only when you hit a real wall.
Code Examples
// MySQL full-text search — hitting limits:
$results = $pdo->query(
"SELECT * FROM glossary WHERE body LIKE '%" . $term . "%'
OR title LIKE '%" . $term . "%'"
);
// 2 second query on 10,000 terms, no ranking, no typo tolerance// Polyglot: MySQL for data, Meilisearch for search:
// MySQL: source of truth for term content
$term = Term::find($slug);
// Meilisearch: optimised for full-text search
$searchResults = $meilisearch->index('glossary')
->search($query, ['limit' => 20]);
// 5ms response, typo-tolerant, ranked by relevance
// Keep in sync via queue:
TermSaved::dispatch($term); // Listener re-indexes in Meilisearch