Databases: Comparison, Choosing & Polyglot
jsonb: Indexes, Tradeoffs & Exercise
You have been working with PostgreSQL since Week 5. It is a solid, battle-tested tool but it is not the right tool for every problem. Real-world backends rarely rely on a single storage solution.
In this section you will learn about two other major categories of databases, understand how they compare to relational databases, and develop the judgement to choose the right one for a given situation.
By the end of this section you will be able to:
Not all data looks the same. A user account, a product catalogue, a session token, a sensor reading, and a social network connection are all very different kinds of data and different database types were built to handle each one well.
Here is a quick overview of the main types you will encounter as a backend developer:
| Database type | What it does | Example |
|---|---|---|
| Relational | Stores data in tables with rows and columns, connected by foreign keys | PostgreSQL, MySQL |
| Document | Stores flexible JSON-like documents — each one can have different fields | MongoDB, CouchDB |
| Key-value | Stores simple key → value pairs in memory — extremely fast | Redis, Memcached |
| Graph | Stores data as nodes and edges — great for relationships between things | Neo4j |
| Time series | Optimised for data tied to timestamps — sensor readings, metrics | InfluxDB, TimescaleDB |
| Search | Built for full-text search across large volumes of text | Elasticsearch |
| Wide column | Like a relational database but each row can have different columns — built for massive scale | Cassandra |
| Vector | Stores data as numbers and searches by similarity — powers most AI features | Pinecone, pgvector |
You already know relational databases well from Week 5, you have been using PostgreSQL since then.
This week you will go deeper into two types that are widely used in real backends alongside PostgreSQL:
A document database stores data as documents self-contained, JSON-like objects. Instead of rows and columns in a table, you have documents grouped into collections.
Think of a document as a small package that carries everything related to one thing. A user document contains the user's name, email, preferences, and even their recent activity all in one place, without needing to join other tables.
MongoDB is the most widely used document database. It stores data in a format called BSON (Binary JSON) which is JSON under the hood, with some extra data types added for efficiency. From a developer's perspective it looks and feels like plain JSON.
This is the biggest conceptual shift coming from PostgreSQL.
In a relational database, every row must follow the same column structure. If you want to add a new field, you must run ALTER TABLE and add the column to every row even if most rows will leave it empty.
In MongoDB, each document in a collection can have a completely different shape. There is no migration. No ALTER TABLE. You just add the field to the document.
Relational (rigid schema):
| id | name | price | color | size | wattage | |
|---|---|---|---|---|---|---|
| 1 | t-shirt | 19.99 | blue | M | NULL | ← Wattage doesn’t apply |
| 2 | lamp | 49.99 | NULL | NULL | 60W | ← color /size don’t apply |
The table forces every product to have the same columns even if they are irrelevant. The result is many NULL values and a fragile schema that gets messier as you add more product types.
MongoDB (flexible schema):
json
// Laptop — has specs and tags
{
"_id": "prod-001",
"name": "Laptop",
"price": 1299.99,
"specs": { "ram": "16GB", "storage": "512GB" },
"tags": ["electronics", "computers"]
}
// T-Shirt — completely different shape, same collection
{
"_id": "prod-002",
"name": "T-Shirt",
"price": 24.99,
"color": "blue",
"sizes": ["S", "M", "L", "XL"]
}
// Lamp — yet another shape
{
"_id": "prod-003",
"name": "Lamp",
"price": 49.99,
"wattage": 60,
"dimmable": true
}
No NULL columns. No awkward workarounds. Each product carries exactly the fields that make sense for it.
| MongoDB concept | Relational equivalent | Key difference |
|---|---|---|
| Database | Database | Same concept |
| Collection | Table | No fixed schema |
| Document | Row | Can have any shape |
| Field | Column | Does not need to exist in every document |
_id |
Primary key | Auto-generated if not provided |
A collection is just a named group of documents. MongoDB does not care if the documents inside share the same fields that is your responsibility to manage.
In a relational database, related data lives in separate tables and is connected with foreign keys. In MongoDB you have a choice: embed the related data inside the document, or reference it by ID.
Embedding — put related data directly inside the document:
json
{
"_id": "post-001",
"title": "Getting Started with Spring Boot",
"author": "Alice",
"tags": ["java", "spring", "backend"],
"comments": [
{ "user": "Bob", "text": "Great post!", "date": "2024-01-10" },
{ "user": "Carol", "text": "Very clear.", "date": "2024-01-11" }
]
}
In PostgreSQL this would require a posts table, a comments table, a join, and potentially a tags join table. In MongoDB it is one document, one read no join needed.
When to embed: the related data always belongs to the parent (comments always belong to a post), the related data is small, and you always read them together.
When to reference: the related data is large, shared across many documents, or updated independently (e.g. a user's full profile referenced from many posts).
This official MongoDB video introduces document databases and explains the core concepts of MongoDB - documents, collections, and flexible schemas - from the ground up.
https://www.youtube.com/watch?v=mBfzfaW8XvM
Good fit:
Not a good fit:
<aside> ⚠️
</aside>
This video from IBM's Martin Keen explores the key differences between relational databases (MySQL) and document databases (MongoDB), explains how each got its name, and helps you understand when to choose one over the other.
https://www.youtube.com/watch?v=OdgZ0jr4jpM
A key-value store is the simplest possible database: you store a value under a key, and retrieve it instantly by that key. Think of it as a giant, extremely fast dictionary or HashMap but one that can be shared across your whole backend.
Redis (Remote Dictionary Server) is the most widely used key-value store. It is open source, runs in memory, and is renowned for being extraordinarily fast.