Choosing a Database

There is no "best" database. The right choice depends on two things:

Data shape: is your data mostly connected records (users, orders, payments that point to each other) or self-contained documents (a menu item, a product page)?
Access patterns: how your app reads and writes the data. Which queries run most, how often, and how much data.

Think of choosing a vehicle. A truck isn't better than a bike. It depends on what you carry and where you're going.

Five Questions to Ask

Question	Points to PostgreSQL	Points to MongoDB
Is the data highly connected?	Yes, many relationships and JOINs	No, mostly read as whole documents
Does correctness matter most?	Yes, money, stock, bookings	Small mistakes are tolerable or rare
Does the shape change often?	Rarely, stable columns	Often, records vary a lot
Do you need complex reports?	Yes, filters, GROUP BY, ad-hoc queries	Mostly simple lookups by id or key
Will writes outgrow one server?	Not soon, one big server + replicas is enough	Yes, need built-in sharding

The last one matters less than people think. A single well-tuned PostgreSQL server handles a lot of traffic, and most apps never need to split data across servers.

Decision Flow

1Is the data highly connected or about money?
2├── Yes → PostgreSQL
3└── No
4    │
5    Do records vary a lot or change shape often?
6    ├── Yes → MongoDB (or PostgreSQL + JSONB)
7    └── No
8        │
9        Do you need huge write scale across many servers?
10        ├── Yes → MongoDB (built-in sharding)
11        └── No  → PostgreSQL (safe default)

Applying It to Our Food Delivery App

Different parts of the same app can have different answers:

Part of the app	Data shape	Good fit	Why
Users, wallets, payments	Connected, money involved	PostgreSQL	Strong transactions, constraints, foreign keys
Orders	Connected to users, restaurants, payments	PostgreSQL	Correctness and reporting ("revenue per restaurant")
Restaurant menus	Varied dishes, nested options	MongoDB or PostgreSQL JSONB	Flexible shape, read as a whole
Rider location pings	Huge write volume, simple shape	MongoDB	High writes, easy to shard
Reviews and photos metadata	Self-contained, varied	MongoDB	Document-shaped, rarely joined

Using more than one database in one system is called polyglot persistence. It's common at scale, often with Redis for caching and Elasticsearch for search. But every extra database is more to run, monitor, and keep in sync. For a new app, start with one and add others only when a real need appears.

Wrong Reasons to Pick a Database

Reason	Why it's weak
"MongoDB is faster"	Speed depends on schema, indexes, and queries, not the brand
"MongoDB doesn't need a schema"	You still need one; it just moves into your code or a validator
"SQL doesn't scale"	Replicas, partitioning, and good indexes take PostgreSQL very far
"Everyone uses X"	Your data and queries decide, not popularity
"JSON is easier in Node.js"	PostgreSQL JSONB and ORMs make SQL easy in Node.js too

Interview Angle

How to Explain it in an Interview

The 30-Second Spoken Pitch

"The choice depends on data shape and access patterns. If the data is highly relational and correctness-critical, like users, orders, and payments, I'd pick PostgreSQL for its transactions, constraints, and JOINs. If the data is document-shaped, read together as one unit, and its structure changes often, like restaurant menus or product catalogs, MongoDB fits well. MongoDB also helps when write volume needs to be split across many servers. Postgres with JSONB covers a lot of hybrid cases, so if I'm unsure, I'd start with Postgres. In a large system, I might use both, but each extra database adds operational cost."

What interviewers look for:

You ask about the data and queries before naming a database.
You give a reason tied to the requirements, not a preference.
You mention trade-offs, not one side only.

Summary

1Decide by     → data shape + access patterns
2Connected / money / reports      → PostgreSQL
3Varied shape / whole-document reads / huge writes → MongoDB
4Unsure        → PostgreSQL (+ JSONB for flexible parts)
5Big systems   → may use both (polyglot persistence), at extra operational cost

Once MongoDB is chosen for part of the system, the key decision becomes how to shape its documents. Next, Mongo Schema Design turns embed vs reference into clear rules.

Next TopicMongo Schema Design (embed vs reference, 16 MB limit)