Learn how to model Firestore data the right way for performance, cost, and scalability. Discover why Firestore is not SQL and how production apps structure data correctly.

Most Firebase apps don’t fail because of authentication.

They don’t fail because of CRUD logic either.

They fail because developers unknowingly treat Firestore like a relational SQL database.

Apps look fine during development.
Then real users show up.
Queries get slower.
Costs increase.
UI state becomes harder to manage.

And it usually traces back to data modeling decisions made early.

Firestore Is Designed For Reads — Not Relationships

If you come from SQL, you were trained to:

Normalize data
Reduce duplication
Join tables when needed

Firestore is different.

Firestore is optimized for:
Fast document reads
Predictable query patterns
Scaling read-heavy apps
Simple security rule evaluation

Instead of designing for relationships, you design for how your app reads data.

The Biggest Mindset Shift

Instead of asking:

“How should this database look logically?”

You should ask:

“How does my UI load data together?”

If your UI loads data together, Firestore usually wants that data stored close together — even if it looks duplicated.

The 5 Production Rules For Firestore Data Modeling

✅ 1. Model Data Based On How You Read It

Design around:

Screens
Components
API responses
User flows

If your Restaurant Page loads:

Restaurant → Menu Categories → Menu Items

Then structuring data around that flow is correct.

✅ 2. Duplication Is Normal If It Reduces Queries

In SQL:

Duplication = bad

In Firestore:

Duplication = often good

Storage is cheap.

Extra reads cost money and performance.

If duplication saves multiple queries → it’s usually worth it.

✅ 3. Optimize For Common Queries — Not Rare Ones

Design for:

Main user flows
Most viewed screens
Most frequent filters

Not:

Admin-only queries
Rare reports
Edge analytics

✅ 4. Subcollections Are Good — But Not For Everything

Subcollections are great for:

Ownership structure
Security boundaries
Logical grouping

But if you need:

Cross-category search
Global filtering
Analytics queries

You may also need a flatter mirror collection.

✅ 5. Structure For UI Rendering — Not Database Purity

Firestore isn’t trying to be relational.

If your UI groups items →

Your database can group items.

Clean relational theory ≠ Best Firestore performance.

Real App Example (Simple Pattern)

A common real-world approach looks like this:

Tree structure for ownership and UI navigation:

restaurants/{restaurantId}/menu-types/{typeId}/menu-items/{itemId}

JavaScript

Copy

Optional flat mirror for queries:

restaurants/{restaurantId}/all-items/{itemId}

JavaScript

Copy

You get:

Clean UI loading
Fast queries when needed
Future flexibility

Most Common Firestore Modeling Mistakes

Trying to simulate SQL joins in queries
Over-normalizing data
Deep nesting then needing global queries
Designing database structure before UI design
Ignoring read count and query cost

If you find yourself merging 3–4 collections client-side —

It’s often a modeling signal, not a query problem.

How Production Teams Think About Firestore

Before finalizing structure, they ask:

How does the UI read this data?
How often is this queried?
Will we need cross-category filtering later?
Will this simplify or complicate security rules?
Will this increase total read cost per screen load?

Firestore modeling is less about database theory and more about application behavior.

If You Want To See This In A Real App Build

When building real Firebase apps, these patterns show up naturally — not as theory, but while building UI, queries, and features together.

If you want to see how production-style Firebase apps are structured step-by-step inside a full working project, you can check out my Firebase course here:

👉 [COURSE LINK]

Disqus Recommendations

We were unable to load Disqus Recommendations. If you are a moderator please see our troubleshooting guide.

❮

3 years ago
1 comment

The onAuthStateChanged() method is triggered when a user's authentication state …

8 months ago

In this FREE course, you're going to learn how to build a simple real-world …

3 years ago

Learn how to get use data from firebase 9 Cloud Firestore database with 3 …

3 years ago

Learn how to use createUserWithEmailAndPassword() to create a new Firebase …

3 years ago

Learn how to authenticate a user account using the …

3 years ago

Learn how to sign out or log out users of their current authentication using …

❯

tempest.services.disqus.com

tempest.services.disqus.com is blocked

This page has been blocked by an extension

Try disabling your extensions.

ERR_BLOCKED_BY_CLIENT

Reload

This page has been blocked by an extension

Disqus Comments

We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.

Start the discussion…

Comment

Log in with

or sign up with Disqus or pick a name

Disqus is a discussion network

Don't be a jerk or do anything illegal. Everything is easier that way.

Read full terms and conditions

This comment platform is hosted by Disqus, Inc. I authorize Disqus and its affiliates to:

Use, sell, and share my information to enable me to use its comment services and for marketing purposes, including cross-context behavioral advertising, as described in our Terms of Service and Privacy Policy, including supplementing that information with other data about me, such as my browsing and location data.
Contact me or enable others to contact me by email with offers for goods or services
Process any sensitive personal information that I submit in a comment. See our Privacy Policy for more information

Acknowledge I am 18 or older

Favorite this discussion
Discussion Favorited!

Favoriting means this is a discussion worth sharing. It gets shared to your followers' Disqus feeds, and gives the creator kudos!

Find More Discussions

Tweet this discussion
- Share this discussion on Facebook
- Share this discussion via email
- Copy link to discussion
Best
- Newest
- Oldest

Be the first to comment.

Load more comments

live.rezync.com

live.rezync.com is blocked

This page has been blocked by an extension

Try disabling your extensions.

ERR_BLOCKED_BY_CLIENT

Reload

This page has been blocked by an extension

pippio.com

pippio.com is blocked

This page has been blocked by an extension

Try disabling your extensions.

ERR_BLOCKED_BY_CLIENT

Reload

This page has been blocked by an extension

Twitter Widget Iframe

Firebase Version 9 Tutorial (Modular)

Firebase Version 8 Tutorial (Namespaced)

Firestore Is Designed For Reads — Not Relationships

The Biggest Mindset Shift

The 5 Production Rules For Firestore Data Modeling

✅ 1. Model Data Based On How You Read It

✅ 2. Duplication Is Normal If It Reduces Queries

✅ 3. Optimize For Common Queries — Not Rare Ones

✅ 4. Subcollections Are Good — But Not For Everything

✅ 5. Structure For UI Rendering — Not Database Purity

Real App Example (Simple Pattern)

Most Common Firestore Modeling Mistakes

How Production Teams Think About Firestore

If You Want To See This In A Real App Build

tempest.services.disqus.com is blocked

Log in with

or sign up with Disqus or pick a name

Disqus is a discussion network

Discussion Favorited!

live.rezync.com is blocked

pippio.com is blocked