MongoDB

mongosh is the official MongoDB Shell — a JavaScript REPL connected to a running server. You point it at a connection string (mongodb://host:port), and from there you select a database with use, then act on collections (the document equivalent of tables). Nothing is created until you write the first document; databases and collections come into existence on first insert. A managed alternative is MongoDB Atlas, where the same connection string is mongodb+srv://... and you skip running the server yourself.

A document is a BSON object — JSON plus extra types like ObjectId, Date, and 64-bit integers. Every document gets a unique _id; if you omit it, MongoDB generates an ObjectId (a 12-byte, time-ordered identifier). Two documents in the same collection need not share the same fields — the schema is implicit and per-document, which is exactly what makes early iteration fast. find() returns a cursor; pass a filter object to narrow it, and a second object to project only the fields you want.

Updates use operators, not a replacement object: $set assigns fields, $inc adds to a number, $push appends to an array, $pull removes from one. A single-document update is atomic, so $inc is a safe, race-free counter without a transaction — two concurrent likes both land. updateOne touches the first match; updateMany touches all. Add { upsert: true } to insert the document when no match exists.

The document model rewards embedding data you read together. A feed post that carries a denormalised author summary ({ id, displayName, avatarUrl }) and its tags renders from one find — no join, no second round trip. The trade-off is duplication: if a display name changes you update it in many places. The rule of thumb is embed bounded, read-together data; reference (store an id) for unbounded or independently mutated data — comments that can grow forever, or an author record edited on its own. This is the opposite instinct from relational normalisation, and it is deliberate: you optimise for the read shape.

Without an index, a query scans every document. An index is an ordered B-tree MongoDB walks instead. For compound indexes, field order matters: follow Equality, Sort, Range — put fields you match exactly first, then the field you sort on, then range fields. A feed query that filters author.id and sorts by createdAt wants { "author.id": 1, createdAt: -1 }. An index on an array field (like tags) is a multikey index automatically — one entry per element. Verify with explain("executionStats"): you want an IXSCAN stage, not a COLLSCAN.

The aggregation pipeline is an array of stages; each consumes the previous stage’s documents and emits new ones. $match filters early (put it first so an index can help and less data flows downstream), $group collapses documents by a key and accumulates ($sum, $avg, $max), and $project reshapes the output — add, rename, or drop fields. This is how you compute “likes per author this week” or “top tags” without pulling raw documents into the application and looping in code.

$lookup performs a left outer join between collections inside an aggregation: for each input document it finds matching documents in another collection and attaches them as an array field. It is the escape hatch for the data you chose to reference — fetching a post’s comments, or hydrating an author record kept in its own collection. It works, and a $lookup on an indexed localField/foreignField is efficient, but if you find yourself joining on every read, that is a signal your model may want more embedding. Joins are not MongoDB’s strong suit the way they are PostgreSQL’s; reach for $lookup, don’t lean on it.

Production MongoDB runs as a replica set: one primary takes writes, secondaries replicate the oplog, and if the primary fails the members elect a new one — that is how you get high availability and automatic failover. You tune the guarantees per operation. A write concern of { w: "majority" } waits until a majority of members have the write, so it survives a failover; { w: 1 } returns after just the primary. A read concern of "majority" returns only data acknowledged by a majority (no reading writes that could be rolled back). Multi-document transactions (next step) require a replica set — another reason it is the realistic baseline, not a single mongod.

MongoDB has full multi-document ACID transactions (on a replica set): start a session, do several writes, commitTransaction — all or nothing. They are real and correct. But they carry cost and contention, and the document model is designed so you often don’t need them: keep the data that must change together in one document, and a single-document update is already atomic. A like, a comment-count bump, a status flip — all one updateOne. Reserve transactions for the genuine cross-document invariant (move an item between two users’ collections). If you reach for transactions on every write, that is the signal a relational database with row-level transactions — PostgreSQL — may fit the problem better. Honesty here saves you pain later.

Implicit schema is a gift while you iterate, but once a collection’s shape stabilises you usually want guardrails so a bad write can’t slip in. MongoDB supports JSON Schema validation per collection: declare required fields and types with $jsonSchema, set validationLevel and validationAction ("error" to reject, "warn" to log). You can tighten an existing collection with collMod. This is the discipline that lets the flexible model scale — flexible where you’re still learning the domain, validated where you’ve committed to it.

A plain MongoDB text index handles basic keyword search, but for real relevance ranking, typo tolerance, and autocomplete you use Atlas Search, a Lucene-based full-text engine built into the managed Atlas service. You define a search index on a collection, then query it with the $search aggregation stage. Atlas also offers Vector Search — store embeddings on your documents and query by nearest-neighbour ($vectorSearch) for semantic search and retrieval-augmented generation, right next to your operational data. These are Atlas features (not the open-source server), so this step assumes a cluster on Atlas.