MongoDB in 8 Slides

Post 4 is the hands-on tour and the cover sets that expectation: this is the post you keep open as a cheat sheet. Every slide is a runnable snippet against a live MongoDB instance, building from the simplest write through to a real aggregation pipeline.

The pedagogical idea is that you learn a database by doing, not by reading definitions. Posts 1 through 3 gave you the model and the mechanics; this post puts your hands on the controls. By the end you'll have seen all four CRUD operations, the everyday query operators, and the pipeline that handles grouping and transformation.

Inserting is the natural starting point because you can't read what you haven't written. insertOne takes a single document — a plain object — and writes it to the collection, creating the collection automatically if it doesn't exist yet. There's no schema to declare first; the document's shape is its schema.

insertMany takes an array and writes them in one call, which is both more convenient and more efficient than looping over insertOne for bulk loads. Note that neither call required you to define the 'orders' collection in advance — that's the flexible-schema model from post 1 in action. Both operations return information about what was inserted, including any _id values the server generated for you.

find is where MongoDB's query language earns its keep, and this slide packs three ideas. The first argument is the filter — a document describing what to match. Here it combines an exact match on status with a range condition using $gt (greater than). MongoDB has a full family of these operators: $gt, $gte, $lt, $lte, $ne, and more.

The second argument is the projection, which controls which fields come back. { user: 1, total: 1, _id: 0 } means 'return user and total, suppress _id'. Trimming returned fields reduces network and memory cost on large documents. Finally, .sort({ total: -1 }) orders results descending. The second example shows $in, which matches a field against any value in a list — the clean way to express 'status is paid OR refunded' without an explicit OR.

Updates in MongoDB use update operators, and the most important distinction for newcomers is that you almost never replace a whole document — you describe a change. $set assigns specific fields, leaving the rest of the document untouched. $inc atomically increments a numeric field, which is the correct, race-safe way to bump a counter rather than reading, adding, and writing back.

updateOne modifies the first matching document; updateMany modifies all matches. The slide also hints at upsert (update-or-insert), where Mongo creates the document if no match exists — useful for 'set this, creating it if needed' patterns. The key safety lesson, expanded in post 5, is that the filter is what scopes the update; a careless or empty filter changes far more than you intended.

Deletes are simple to write and dangerous to get wrong, which is why this slide leads with the danger. deleteOne removes the first document matching the filter. deleteMany removes all matches. Both are driven entirely by the filter you supply.

The commented line is the footgun the whole slide is built around: deleteMany({}) with an empty filter matches every document and wipes the collection. There's no confirmation prompt, no undo. The safe habit shown in the live line is to always pass a specific, scoped filter — and, as post 5 advises, to run the same filter through find() first to see exactly what you're about to destroy. Treating destructive operations with this caution is a discipline, not a feature the database enforces for you.

The aggregation pipeline is MongoDB's analytics engine and the single most powerful query tool it offers. The model is a pipeline of stages, where each stage transforms the stream of documents and passes the result to the next — conceptually like piping commands in a Unix shell.

This example computes revenue per user in three stages. $match filters to paid orders, which also lets the planner use an index and shrink the dataset early. $group is the heart of it: it groups documents by user (_id: '$user') and accumulates a sum of their totals. $sort orders the grouped results by revenue, descending. The $-prefix on field names ('$user', '$total') means 'the value of this field'. Master $match, $group, and $sort and you can express the large majority of real analytical queries.

The pipeline diagram visualizes the same aggregation as a flow of stages, which is the right mental model: documents enter on the left and flow through each stage, transformed at every step, until final documents emerge on the right. $match filters, $group collapses many documents into summary documents, $sort orders them, and the output is your result set.

The practical lesson encoded here is ordering. Putting $match first — before $group — means you filter the data down before doing the expensive grouping work, and a well-placed $match can use an index. Reordering stages changes both correctness and performance, so thinking of aggregation as an ordered pipeline rather than one opaque query is exactly the right instinct.

This slide combines two everyday patterns that work better together: indexing the field you query, and upserting on it. createIndex({ user: 1 }) makes lookups by user fast, which matters because the upsert that follows has to find any existing document first. An upsert is update-or-insert: if a matching document exists it's updated, otherwise it's created.

The operators chosen show the nuance. $inc bumps a visit counter on every call. $setOnInsert sets createdAt only when the document is first created, never on subsequent updates — so the creation timestamp stays accurate. With { upsert: true }, this single statement safely handles both 'first time we've seen ada' and 'ada again' without you writing a find-then-branch. Pairing the index with the upsert avoids the slow scan that an unindexed upsert would otherwise trigger on every call.

This slide proves that everything you've seen translates directly to a real application driver, not just the shell. PyMongo is the official Python driver, and the API is intentionally close to the shell syntax: insert_one, find, and the same query operators expressed as Python dicts.

MongoClient connects to the server, .shop selects the database, and .orders selects the collection. find returns a cursor you iterate over lazily — it doesn't load every result into memory at once, which matters for large result sets. The operators are identical: {'total': {'$gt': 10}} is the same $gt you used in the shell. The takeaway is that the concepts are portable; once you know the query model, switching from the shell to Python, Node, Go, or Java is mostly syntax.

The cheat-sheet recap is the post's deliverable — five lines that cover the daily working set of MongoDB operations. insertOne and insertMany to write; find with a filter, projection, and sort to read; the everyday operators $set, $inc, $in, and $gt; aggregate for grouping and transformation; and the safety rule to always scope deletes.

The last bullet is repeated on purpose because it's the one that causes real damage. Speed of recall on the first four lines makes you productive; remembering the fifth keeps you from wiping a collection. Together they're enough to handle the majority of real CRUD and reporting work.

This cover closes the code tour and sets up the final post. You've now written, read, updated, deleted, and aggregated — you can drive MongoDB. The natural next step is learning the ways people drive it into a wall.

The teaser frames post 5 around mistakes: the performance and data-integrity failures that don't show up in a tutorial but absolutely show up in production. Knowing the happy path is half the job; knowing the failure modes is what makes you trustworthy with a real database.