Polyglot Persistence
Polyglot Persistence uses multiple storage technologies for different data needs. Each additional technology increases operational and synchronization effort.
- Relevant sourceThere the binding status applies.
- Derived memoryIt is filled from the source.
- Operating costsEvery store needs care.
Context
Why this is important
Several memories are only worthwhile with a clear task and a clear authoritative source, because each memory costs operation. Which model fits an access shows SQL & NoSQL; this is about the combination and its price.
This building block explains the combined use of different memories. For the selection of a single model, see SQL & NoSQL.
At a glance · Every service, suitable memory
What storage does the shop carry?
Variant: The grown shop keeps orders relational, searches for products in a search index and stores product images in an object memory. The shop remains technically modular.
This is how you read the picture
- Relevant source The relational database for orders and status.
- Derived memory The search index is derived from the catalogue.
- Operating costs The points per memory against the capacity of 8.
5 of 8 PointsWhat the small team can do reliably
Still 3 Points Free. Everything that is spent is documented.
Values illustrative
Benefits & limitations
Helps if:
- Different access patterns can use a suitable storage model for each data area.
- A derived view complements the authoritative source for specialised access patterns poorly served by its data model.
- A team with capacity for additional operation and reconciliation can responsibly connect multiple storage facilities.
Boundaries
- Every additional store needs installation, monitoring, backups, updates and team expertise.
- Derived data must be reconcilable and rebuildable from the source when necessary.
- There is no common transaction across multiple stores; coordinated flows require a Saga.
In practice
- Assign each store a clear purpose, a binding source, and a responsible team. Determine which data is only derived or cached.
- Define reconciliation, failure handling and rebuilding between stores. Compare control values so a projection can be trusted again after a failure.
- Weigh operational and consistency management costs against measured benefits. SQL & NoSQL compares storage types; Data Ownership clarifies authoritative ownership.
Read the detailed explanation
Polyglot Persistence combines stores with different data models and access characteristics. Each store has a bounded purpose, an owner and its own operational procedures. An explicit authoritative source defines where changes are accepted.
Search indexes, caches and other projections can be derived from that source. Synchronisation may lag and must handle failures and rebuilding. Every additional store adds backup, monitoring, on-call and consistency management work.
Persistence covers selecting the primary store; Data Ownership establishes which source has authority to accept changes.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many points do the three occupied memories consume, and how much budget remains?
View the solution with justification
5 from 8 Points; remain 3 Points.
ApplyingTransferred to a new situation
The team also wants to turn on the analysis memory. What does the budget show?
View the solution with justification
With 3 Other points would be 8 from 8The budget is exhausted, and the need is only suspected.
EvaluateWeighing an alternative
Should the store outsource sessions to its own key-value store? How do you weigh up?
View the solution with justification
It would be appropriate for this access, but the relational database carries sessions today. Without a proven need, it costs 2 Points of operation; recommendation: not at first.
Explore further
These building blocks continue the thoughts of this page.
References
- Martin Fowler · Polyglot Persistence (opens in new tab)Justifies different data storage based on different access needs.
- Microsoft · Data Store Models (opens in new tab)Compares data models and typical storage conditions.
- microservices.io · Database by Service (opens in new tab)Describes data responsibility, API access, and query consequences.