New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom NoSQL fundamentals to a production-ready MongoDB architecture.
A 12-step learning path. Follow it in order, or jump to what you need.
For developers and data folks who already know their way around a database and want real command of MongoDB and the wider NoSQL landscape, not just enough syntax to spin up a collection. Plan on about 5 to 7 weeks at a few hours a week, moving from the shape of the NoSQL landscape through document modeling into a full MongoDB deployment, then out to the stores that specialize where MongoDB doesn't. This path stays inside document, key-value, wide-column, and graph NoSQL stores; if your work leans toward normalized tables and a single relational engine, the SQL & Relational Databases path covers that ground instead. By the end you can model a document schema around real access patterns, run and tune a production MongoDB deployment with transactions, indexes, and security in place, and choose the right NoSQL store, or combination of stores, for a given system design.
Expected: comfort writing basic code or SQL queries and reading JSON. Helpful but not required: hands-on time with a relational database.
Open this first and you'll know within minutes whether a job calls for a relational table, a document, a graph, or a vector store, the map every later step in this path fills in one piece at a time.
Go deeper into the NoSQL half of step 1's map: consistency levels, CAP theorem trade-offs, and the operational reality of running a non-relational store, the concepts every product-specific step from here on assumes you already have.
This is where the relational instinct stops helping: modeling for how your app reads data, embedding over joining, denormalizing on purpose, expect the mindset shift to take a few tries before it clicks.
You can size up any dataset and match it to the right database family, then model a document schema around how your app actually reads data, not how it happens to be stored. Next up: putting all of that to work inside MongoDB itself.
Finish this section to unlock.
+100 XP
Put the modeling patterns from step 3 into a real document database: CRUD, the aggregation pipeline, indexing, and Atlas features, the one store this whole path is built around.
MongoDB's multi-document transactions from step 4 only make sense once you know what they're buying you: ACID guarantees, isolation levels, and the concurrency anomalies they prevent.
Keep the MongoDB cluster from step 4 from buckling under read traffic: cache-aside, write-through, and invalidation patterns that make the dedicated Redis deep-dive later in this path click faster if you take it.
Lock down what steps 4 through 6 built: encryption, role-based access, and audit logging so the database you've been shaping stays yours alone.
You can query, aggregate, and index a MongoDB collection, wrap multi-document writes in a real transaction, and cache and lock down the whole thing the way a live system needs (a few minutes of due flashcards keeps chapter 1's modeling patterns fresh while you build on them here). Next up: seeing where MongoDB fits next to the rest of the NoSQL family.
Finish this section to unlock.
+100 XP
Take this if your app needs sub-millisecond reads or a lightweight message broker alongside MongoDB: Redis turns the caching ideas from step 6 into a dedicated in-memory store with its own data structures.
Reach for this if you're writing at a scale MongoDB's single-primary model starts to strain: Cassandra's peer-to-peer architecture and query-first modeling trade the consistency step 3 taught you for raw write throughput.
Grab this if your data is really about connections, social graphs, fraud rings, recommendation chains: Cypher's pattern matching finds relationships that a MongoDB lookup from step 4 would need multiple round trips to assemble.
Pick this up if you're heading toward AI or RAG work: vector databases store embeddings instead of documents, a similarity search model that step 3's modeling patterns don't cover at all.
Bring every store this path touched into one conversation: when to shard, when to replicate, and which of MongoDB, Redis, Cassandra, or Neo4j actually fits a given system's access pattern, the question a real architecture review always asks.
You can reach for MongoDB, Redis, Cassandra, or Neo4j depending on the job, weigh CAP theorem trade-offs and sharding strategy like an architect, and defend a real database choice in a system design conversation, that's the MongoDB & NoSQL Databases badge, earned.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.