PostgreSQL vs MongoDB: how to actually choose

This is the question I got asked most as a junior, and the answers online are usually useless — "Mongo is for unstructured data", "Postgres is for relations". Technically true, practically unhelpful.

Let me try to explain it the way I wish someone had explained it to me.

Step 1: How each one stores your data

PostgreSQL stores rows in tables

You define the shape first. Every row must match it.

CREATE TABLE users (
  id       SERIAL PRIMARY KEY,
  email    TEXT NOT NULL UNIQUE,
  name     TEXT NOT NULL,
  created  TIMESTAMP DEFAULT now()
);

If you try to insert a user without an email, the database rejects it. The rules live in the database, not in your code.

MongoDB stores documents in collections

A document is basically JSON. There is no fixed shape unless you add one.

{
  "_id": "65f...",
  "email": "nikhil@example.com",
  "name": "Nikhil",
  "address": { "city": "Indore", "country": "India" },
  "tags": ["backend", "node"]
}

Notice the nested object and the array. In Postgres those would normally be two extra tables. In Mongo they sit inside the same document.

Step 2: The question that actually decides it

Forget "structured vs unstructured". Ask this instead:

When I read this data, do I usually need it all together, or do I need to combine it with other things in ways I cannot predict?

That is the whole decision.

• Read together, always: a blog post with its tags and author name. A product with its images and specs. This fits a document. One read, no joins. Mongo is comfortable here.
• Combined in unpredictable ways: "total revenue per city per month for users who signed up after March and bought more than twice". That is joins and aggregation across many entities. Postgres is much better here.

Step 3: Things that surprise people

"Mongo is faster"

Only for the shape it likes — fetching one whole document by id. Once you start doing $lookup (Mongo's version of a join) across three collections, Postgres will usually beat it. And a Postgres query on a properly indexed table is extremely fast.

In practice, the thing that made my APIs slow was never the database engine. It was missing indexes. I improved API performance by about 40% at one job almost entirely by adding the right indexes and fixing N+1 queries — same database, same hardware.

"Postgres cannot do JSON"

It can, and well. The JSONB column type stores real JSON, you can index inside it, and you can query nested fields:

SELECT * FROM events
WHERE payload->>'type' = 'order_filled';

So "I have some flexible fields" is not a reason to pick Mongo any more. You can have a strict table with one flexible JSONB column. I do this often — it is the best of both.

"Schemaless means no schema"

It does not. Your data still has a shape — the shape just lives in your application code now, spread across every file that touches that collection. Six months in, you will find documents from three different eras of your app sitting in the same collection, and nothing stopped that from happening. Mongoose schemas help, but they are enforced by your app, not the database.

Step 4: A simple decision list

Pick PostgreSQL when

• Your data has clear relationships — users, orders, payments, invoices.
• You care about correctness: money, bookings, inventory, anything you cannot get wrong.
• You will need reporting or analytics later. You will.
• You want the database to reject bad data instead of trusting every developer.

Pick MongoDB when

• Documents are naturally self-contained — logs, events, content, product catalogs.
• The shape genuinely varies per record and you are fine handling that in code.
• You are writing a very high volume of independent records.
• Your team already knows it well. This matters more than people admit.

Step 5: My honest default

If I am unsure, I start with PostgreSQL. Not because Mongo is bad — I have used it heavily and it is genuinely good at what it is good at. But an unsure project is one where requirements will change, and changing requirements usually mean new relationships and new queries you did not plan for. Postgres handles that better, and JSONB covers the flexible parts.

The reverse mistake is more painful. Rebuilding relational logic on top of a document store — joins in application code, manual consistency between collections — is a lot of work you did not need to do.