We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Database Types Storage
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Types Storage
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
An e-commerce platform has these data needs:
One database handling all of this is either mediocre at everything or good at one thing and terrible at the rest. PostgreSQL can technically do all of these, but it'll be slow at full-text search, wasteful for ephemeral sessions, awkward for varied product schemas, and punishing for real-time analytics.
Polyglot persistence is the architectural pattern of using multiple, specialized database technologies within a single system, each chosen for the specific data access pattern it serves best.
The term was coined by Martin Fowler in 2011, and it's become the standard approach for any system operating at scale.
Here's how that e-commerce platform might look with polyglot persistence:
| Data Need | Database | Why This One |
|---|---|---|
| User accounts, orders | PostgreSQL | transactions, relational JOINs, mature system |
| Product catalog | MongoDB | Flexible schemas, varied attributes per product type |
| Shopping cart, sessions | Sub-ms reads, expiry, ephemeral data | |
| Product search | Full-text, faceting, typo tolerance, relevance ranking | |
| Recommendations | Neo4j | Graph traversal, "bought together" paths |
| Analytics | ClickHouse or BigQuery | Columnar storage, fast aggregations over millions of rows |
| Event streaming | Apache | High-, ordered event log |
Each database is optimized for its specific access pattern. Redis doesn't need durability guarantees for shopping carts, if a cart is lost, the user adds items again. Elasticsearch doesn't need ACID transactions for product search, eventual consistency (a few seconds delay after product update) is fine. PostgreSQL handles the critical path where consistency matters, payments and order records.
The data flows between them:
When a product is updated in MongoDB, a change event triggers an update to Elasticsearch (for search) and ClickHouse (for analytics). When a user places an order, PostgreSQL records it, Redis clears the cart, and Kafka publishes an event that updates the recommendation graph in Neo4j and the analytics store.
This event-driven synchronization is how polyglot systems keep data consistent across databases.