--- title: Firestore Data Modeling Guide: Embedded Documents vs... description: A comprehensive guide to Firestore data modeling for developers transitioning from relational databases. Covers the core difference between SQL normalization... canonical: https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study) | daily.dev og:description: A comprehensive guide to Firestore data modeling for developers transitioning from relational databases. Covers the core difference between SQL normalization... og:url: https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3 og:image: https://api.daily.dev/og/posts/xsTRcq8U3.png og:image:alt: Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study) **[freeCodeCamp](https://daily.dev/sources/freecodecamp)** · 12 min read · 1 upvotes · 0 comments ## Summary A comprehensive guide to Firestore data modeling for developers transitioning from relational databases. Covers the core difference between SQL normalization and NoSQL denormalization, Firestore's document/collection structure, and two primary strategies: embedding (nesting data in a document) vs. referencing (splitting into separate collections with denormalized fields). Explains how to model 1-1, 1-N, and N-N relationships with concrete code examples, and walks through a blog case study with posts, comments, and likes. Also covers key pitfalls like the 1 MB document limit, hotspotting from sequential IDs, composite index requirements, and write rate limits on hot documents. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### When should I embed data versus use a reference in Firestore? Embed small, bounded lists directly inside a parent document, such as tags on an article or a short list of favorites, since a single read retrieves everything and consistency is guaranteed. Use referencing (separate collections or sub-collections) for dynamic, fast-growing data like comments or order history, since Firestore documents have a hard 1 MB size limit and unbounded embedded lists risk hitting it. _Developers choosing between embedding and referencing in Firestore can compare data modeling approaches on daily.dev._ ### How do you model a many-to-many relationship in Firestore since there's no join table? Use one of three patterns: a junction collection (equivalent to a SQL pivot table) with fields like userId and groupId that can be queried from either side; ID arrays on both sides (cross-denormalization) for fast reads but only when lists stay small; or a hybrid approach using an array for lightweight, rarely-queried relationships and a junction collection for frequently queried, frequently changing ones like team memberships. _Anyone designing many-to-many schemas in Firestore can dig deeper into these patterns via daily.dev._ ### What is the recommended write rate limit for a single Firestore document and how do you fix contention? The recommended maximum sustained write rate to a single Firestore document is about 1 write per second; short bursts of 5-50 writes can be absorbed by queuing, but sustained traffic above that rate produces contention errors. A global counter updated by many users is a common culprit, and the standard fix is a sharded counter that splits the count across several sub-documents and sums them at read time. _Teams hitting Firestore write contention on hot documents can find scaling patterns like sharded counters on daily.dev._ ## Similar posts on daily.dev - [How Firestore Structures Data and How to Perform CRUD Operations With It](https://daily.dev/posts/how-firestore-structures-data-and-how-to-perform-crud-operations-with-it-odioykply) · freeCodeCamp · 1 upvotes · 0 comments - [DocumentDB vs Firestore vs MongoDB](https://daily.dev/posts/documentdb-vs-firestore-vs-mongodb-0cd2hhegv) · Towards Dev · 1 upvotes · 0 comments - [NoSQL Database Evaluation: A Hands-On Guide](https://daily.dev/posts/nosql-database-evaluation-a-hands-on-guide-bzkubfz76) · Couchbase · 1 upvotes · 0 comments - [Building a scalable document management system: Lessons from separating metadata and content](https://daily.dev/posts/building-a-scalable-document-management-system-lessons-from-separating-metadata-and-content-0754llh1s) · InfoWorld · 0 upvotes · 0 comments - [Migrating from SQL to MongoDB](https://daily.dev/posts/migrating-from-sql-to-mongodb-rt90x6pa6) · Laravel News · 0 upvotes · 0 comments --- Tags: [#firebase](https://daily.dev/tags/firebase), [#nosql](https://daily.dev/tags/nosql), [#firestore](https://daily.dev/tags/firestore) [View this post on daily.dev](https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study)","url":"https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3"},"datePublished":"2026-07-24T17:50:04.642Z","dateModified":"2026-09-13T20:18:27.591Z","description":"A comprehensive guide to Firestore data modeling for developers transitioning from relational databases. Covers the core difference between SQL normalization...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f0321aa2e92dcfca83301614d6ccc9bd?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f0321aa2e92dcfca83301614d6ccc9bd?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"freeCodeCamp","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"freeCodeCamp","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1628412854/logos/freecodecamp","url":"https://daily.dev/sources/freecodecamp"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"firebase,nosql,firestore","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"freeCodeCamp","item":"https://daily.dev/sources/freecodecamp"},{"@type":"ListItem","position":3,"name":"Firestore Data Modeling Guide: Embedded Documents vs Referencing (with a Blog Case Study)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/firestore-data-modeling-guide-embedded-documents-vs-referencing-with-a-blog-case-study--xstrcq8u3#faq","mainEntity":[{"@type":"Question","name":"When should I embed data versus use a reference in Firestore?","acceptedAnswer":{"@type":"Answer","text":"Embed small, bounded lists directly inside a parent document, such as tags on an article or a short list of favorites, since a single read retrieves everything and consistency is guaranteed. Use referencing (separate collections or sub-collections) for dynamic, fast-growing data like comments or order history, since Firestore documents have a hard 1 MB size limit and unbounded embedded lists risk hitting it. Developers choosing between embedding and referencing in Firestore can compare data modeling approaches on daily.dev."}},{"@type":"Question","name":"How do you model a many-to-many relationship in Firestore since there's no join table?","acceptedAnswer":{"@type":"Answer","text":"Use one of three patterns: a junction collection (equivalent to a SQL pivot table) with fields like userId and groupId that can be queried from either side; ID arrays on both sides (cross-denormalization) for fast reads but only when lists stay small; or a hybrid approach using an array for lightweight, rarely-queried relationships and a junction collection for frequently queried, frequently changing ones like team memberships. Anyone designing many-to-many schemas in Firestore can dig deeper into these patterns via daily.dev."}},{"@type":"Question","name":"What is the recommended write rate limit for a single Firestore document and how do you fix contention?","acceptedAnswer":{"@type":"Answer","text":"The recommended maximum sustained write rate to a single Firestore document is about 1 write per second; short bursts of 5-50 writes can be absorbed by queuing, but sustained traffic above that rate produces contention errors. A global counter updated by many users is a common culprit, and the standard fix is a sharded counter that splits the count across several sub-documents and sums them at read time. Teams hitting Firestore write contention on hot documents can find scaling patterns like sharded counters on daily.dev."}}]} ```