Polyglot Persistence

Definition

Rather than forcing every workload into one database, each is served by the engine that fits: relational for transactions, a search index for text, a key-value store for sessions, a time-series store for metrics, a graph store for traversal.

When it is right

The justification must be a workload characteristic that the incumbent genuinely cannot serve:

• Full-text and faceted search. A dedicated index is not a preference; a relational engine cannot do relevance ranking well at scale.
• Very high write-rate time-series. Metrics at millions of points per second have an access pattern purpose-built engines exploit.
• Deep graph traversal. Six-hop queries as recursive joins are painful and slow.
• Session and cache data. In-memory stores serve at a latency and cost a durable database cannot match.

Netflix's estate is polyglot for exactly these reasons: viewing history, recommendations, streaming telemetry, and configuration have genuinely different access patterns, volumes and consistency requirements, and the scale is large enough that the difference is decisive.

The cost that gets underestimated

Each additional store carries a fixed operational burden that does not shrink with usage:

• Backup and, more importantly, tested restore.
• Upgrade and patching cycles.
• Monitoring, alerting and capacity planning.
• On-call expertise — someone must know why this engine is behaving oddly at 3am.
• Security review, access control and audit.
• No transactions across stores, so consistency between them becomes application code.

That last point is the architectural one. Two stores holding related data will diverge. Something must detect and repair it, and that reconciliation is permanent work.

The scale threshold matters: the same decision that is correct for Netflix is frequently wrong for a company with ten engineers, because the operational cost is roughly fixed while the benefit scales with workload size.

Failure scenarios

• Each team choosing its favourite, producing six engines in a system where two would do — usually visible as a platform team unable to support any of them well.
• Dual writes between stores without reconciliation, so they silently diverge.
• A specialised store adopted for a workload the primary handled fine, adding operational cost for a benefit nobody measured.
• The second store becomes a single point of failure because a critical path now depends on it with no fallback.

Trade-offs

Bought: the right tool per workload, better performance and cost at genuine scale. Sold: operational simplicity, cross-store transactions, and organisational focus.

The pragmatic default: one relational database until a specific workload demonstrably cannot be served by it, then add exactly one store for that workload, with the reasoning recorded. Modern relational engines cover JSON, full-text, geospatial and queue-like workloads adequately at moderate scale, which pushes the threshold much further out than most teams assume.

Interview question

"A team wants to add a graph database for a social feature. What evidence would justify it, and what would you propose instead?"