Databases: Comparison, Choosing & Polyglot

Teachers

Comparison: Relational vs Document vs Key-Value

	Relational (PostgreSQL)	Document (MongoDB)	Key-Value (Redis)
Data model	Tables, rows, columns	JSON-like documents	Key → value pairs
Schema	Strict, enforced	Flexible, per-document	None
Query language	SQL	MongoDB Query Language	Simple commands (GET, SET…)
Relationships	Foreign keys + joins	Embedded or by reference	Not supported
Speed	Fast	Fast	Extremely fast (in-memory)
Persistence	Always on disk	Always on disk	Optional
Transactions	Full ACID	Limited (single document)	Limited
Scalability	Vertical (primarily)	Horizontal (sharding)	Horizontal
Best for	Structured, relational data	Flexible / nested data	Caching, sessions, speed
Typical use	Orders, users, invoices	Catalogs, CMS, profiles	Cache, sessions, counters

Thinking About It Differently

Each database type optimises for a different thing:

PostgreSQL optimises for correctness — relationships, constraints, and transactions make sure your data stays consistent.
MongoDB optimises for flexibility — the schema can evolve, and data that belongs together travels together.
Redis optimises for speed — by keeping everything in memory and keeping the data model simple, it achieves the lowest possible latency.

Choosing the Right Database

There is no single "best" database. The right choice depends on your data shape and how you access it. These questions will guide you:

Decision Framework

Step 1 — How structured is your data?

Very structured, consistent fields across all records → PostgreSQL
Varies significantly per record, nested data → MongoDB
Simple key lookup, temporary data → Redis

Step 2 — Do you need to query across multiple related entities?

Yes, complex joins are needed → PostgreSQL
No, data is self-contained per document → MongoDB

Step 3 — What are the speed requirements?

Sub-millisecond response, in-memory speed → Redis
Normal database latency is fine → PostgreSQL or MongoDB

Step 4 — Does the data expire?

Yes, auto-expiry is needed → Redis with TTL
No, data is permanent → PostgreSQL or MongoDB

Step 5 — How large is the dataset?

Gigabytes to terabytes of persistent data → PostgreSQL or MongoDB
Smaller hot dataset that fits in RAM → Redis

Scenario Quick Reference

Scenario	Best choice	Why
User accounts and login credentials	PostgreSQL	Structured, needs integrity constraints
Order history and payments	PostgreSQL	Transactions, joins across tables
Product catalog (varying attributes per type)	MongoDB	Different fields per product type
Blog posts with embedded comments	MongoDB	Nested, self-contained documents
User session / login token	Redis	Fast lookup, must auto-expire
Cache for expensive DB query results	Redis	In-memory speed, TTL
Rate limiting (requests per minute)	Redis	Atomic counters, TTL
Real-time game leaderboard	Redis	Sorted sets, instant updates
Financial transactions	PostgreSQL	Full ACID guarantees required
Rapidly changing API response data	MongoDB	Schema can evolve without migration

Polyglot Persistence

What is Polyglot Persistence?

Polyglot persistence means deliberately using more than one type of database in a single application - choosing each one based on what it does best for that specific part of the system.

<aside> 💡

The word polyglot means "speaking multiple languages." Polyglot persistence means your system "speaks" multiple database languages, SQL for structured data, document queries for flexible data, Redis commands for speed.

</aside>

The core idea: no single database excels at all workloads. Rather than forcing all data into one database and accepting the compromises that come with it, you match each dataset to its natural home.

A Real-World Example

Think about what happens in those few seconds when you open Netflix:

A graph database finds shows related to your viewing history
A document store retrieves your viewing history
A key-value cache (Redis) serves your session data
A relational database handles your billing information

All four happen simultaneously, seamlessly, to deliver your homepage. That is polyglot persistence in production.

An E-commerce System

Here is how a backend might distribute data across multiple databases:

Each database handles only what it is good at:

Data	Database	Reason
Users, orders, payments	PostgreSQL	Structured, needs transactions and joins
Product catalog	MongoDB	Different product types have different fields
User sessions	Redis	Fast lookup, auto-expires after inactivity
Recently viewed items (cache)	Redis	Avoid hitting MongoDB on every page load
Password reset tokens	Redis	Short-lived, must auto-expire after 15 minutes

The Benefits

Performance — each database is optimised for its specific workload, so nothing is compromised. PostgreSQL is not slowed down by unstructured data. Redis is not burdened with complex joins.

Independent scaling — if your product catalog grows to millions of items, you scale MongoDB independently. If your session volume spikes, you add more Redis memory. You never have to scale everything together.

Flexibility — if a better database for a specific use case emerges, you can adopt it for that one part without rewriting your whole data layer.

The Trade-offs — It is Not Free

Multiple databases mean multiple systems to install, configure, monitor, backup, secure, update, and maintain. Developers will need to understand multiple database systems, their query languages, and their APIs.

In practical terms:

More operational complexity — more things to set up, monitor, and keep running
Data consistency is your responsibility — if the same piece of information lives in two databases, keeping them in sync is your problem
Higher learning curve — every new database type the team must learn slows down development
More failure points — each additional database is another system that can go down

When Polyglot Persistence Makes Sense

Polyglot persistence becomes necessary when application data needs vary significantly across features or services. It is common in large platforms, distributed systems, and products handling high traffic and diverse workloads.

Good signals that you might need it:

You are caching with PostgreSQL and it feels wrong (use Redis)
Your product catalog has wildly different fields per category (consider MongoDB)
You are storing session tokens as database rows with a cleanup job (use Redis with TTL)
Different teams own different services with fundamentally different data shapes

Bad reasons to add a new database:

"It is trendy"
"We might need it someday"
"It is what Netflix uses"