This step establishes the data layer of the application. You will connect to a local MongoDB instance, write Mongoose models that define every collection and its shape, and verify the connection. Understanding how to design a document schema and when to embed vs. reference is a core MongoDB skill that interviewers frequently probe.
MongoDB is a document database. Instead of tables with rows and columns, data is stored as JSON-like documents (called BSON internally) inside collections. Documents within a collection do not need to share the same shape, though in practice you enforce a consistent shape via Mongoose schemas.
You will run it locally via Docker. In production, you will use MongoDB Atlas, which is a hosted MongoDB service with a free shared cluster (M0, 512MB).
Resources:
Mongoose is the standard ODM (Object Document Mapper) for MongoDB in Node.js. It lets you define schemas that enforce types, required fields, defaults, and indexes on your collections. Unlike a raw MongoDB driver, Mongoose gives you validation, middleware (pre/post hooks), and a clean model API.
Why not the raw MongoDB Node.js driver? The same reason you use Knex over raw SQL: Mongoose adds structure, and for a portfolio project, demonstrating schema design with explicit types and indexes is more valuable than raw driver usage.
Resources:
MongoDB gives you a choice that relational databases do not: you can embed related data directly inside a document (as a subdocument or array), or reference it via an ID (like a foreign key).
Embed when: the child data is always read with the parent, the child does not grow unboundedly, and the child has no independent existence. The oauthToken inside User is a perfect embed — it is always read with the user, there is exactly one, and it exists only in the context of a user.