MongoDB stores records as documents in collections. A useful data model reflects how the application reads and updates information. Before choosing fields, list the screens and operations the application must support, how related records change, and how large collections may become.
Embedding and referencing
Embedding related information can make a common read straightforward when the related data is usually used together and remains bounded. Referencing may be more appropriate when records change independently, are shared by many documents or could grow without limit. These are design trade-offs rather than universal rules; consider consistency, update frequency and query behavior.
CRUD and validation
Create, read, update and delete operations form a basic persistence workflow. Keep field names and types consistent, validate requests at the API boundary and decide how missing or malformed records are handled. Never assume a client-provided identifier or filter is valid.
Queries and indexes
Use filters and projections to retrieve the fields the application needs. Sorting, pagination and indexes should reflect actual query patterns. An index may improve a read but uses storage and adds work to writes. Add indexes intentionally and verify their effect rather than indexing every field by default.
Protect the database
Keep connection strings outside source control, restrict access to what the application requires and avoid logging sensitive documents. Use separate configuration for development and deployment. Test the application's behavior when a record is missing or the database is unavailable.
Practice exercise
Design document shapes for a fictional task board. Identify common reads and updates, decide which data to embed or reference, implement a small CRUD flow and explain one index based on a query you expect to run. Use synthetic records only.
See the MERN Full Stack Developer Course and its MongoDB data-modeling topic guide.