Polyglot Persistence

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

References

• ↗ https://martinfowler.com/bliki/PolyglotPersistence.html

Tags

Related Terms