MongoDB

MongoDB stores data as JSON-like documents rather than rows in tables. Each document can have its own shape, so records with varied or evolving fields don't need a fixed schema decided up front.

Who gets this pick

You'll see MongoDB when your data is flexible or varied (documents, logs), you've used a database before or are comfortable with them, and you're not on shared hosting (where MongoDB is rarely available). If you're new to databases, Stack Picker deliberately steers you to SQL first - most "varied" data still fits tables fine, and SQL is the more transferable skill.

When MongoDB is the right tool - and when it isn't

Good fits: product catalogues where a shoe, a laptop and a sofa each have different attributes; event and activity logs; CMS content with optional, nested fields; data you receive as JSON from other systems and mostly read back whole.

Poor fits: data that's heavily relational - customers, orders, products and invoices that you constantly combine in different ways. MongoDB can do lookups between collections, but if most of your queries are joins, a relational database will be simpler and safer.

A first project: a product catalogue API

Create a free cluster on MongoDB Atlas (its free tier is plenty for learning), copy the connection string, and try the official Node.js driver:

import { MongoClient } from "mongodb";

const client = new MongoClient(process.env.MONGODB_URI);
const products = client.db("shop").collection("products");

await products.insertOne({
  name: "Trail running shoe",
  price: 89,
  tags: ["running", "outdoor"],
  specs: { weightGrams: 280, drop: "6mm" },
});

const cheapOutdoor = await products
  .find({ tags: "outdoor", price: { $lt: 100 } })
  .toArray();
console.log(cheapOutdoor);
await client.close();

Notice that tags: "outdoor" matches any document whose tags array contains that value - a query that needs a separate table in SQL. From here, wrap the queries in an Express API, add products with completely different specs, and add an index on tags.

Designing documents

• Embed what you read together. A blog post's comments might live inside the post document if you always show them together and there aren't thousands.
• Reference what grows without limit or is shared - store a user's id on each order rather than every order inside the user.
• Still have a schema. Flexible doesn't mean unplanned. Use MongoDB's built-in JSON Schema validation, or a library like Mongoose, to enforce the fields you rely on.
• Index for your queries. Without indexes, every query scans the whole collection.

Mistakes to avoid

• Choosing MongoDB to avoid learning SQL. You'll meet relational data eventually, and you'll be learning MongoDB's query language instead anyway.
• Arrays that grow forever inside a document. Documents are capped at 16 MB, and huge ones are slow to read and update.
• No validation, so every typo in a field name quietly becomes a new field.
• Opening your Atlas cluster to every IP address with a weak password. Restrict network access and use a strong, unique database user password.

The alternative to consider

PostgreSQL's JSONB columns let you store and index flexible JSON alongside normal relational tables. If your data is mostly structured with some variable parts, that hybrid is often the better choice - see the PostgreSQL pick.

Keep going