Firestore schema design: 9 patterns that scale (and 3 that don't)

Start from the queries, not the entities

In a relational database you design tables and then write joins. In Firestore there are no joins, so the shape of your data has to mirror the shape of your reads. Before you create a single collection, list the screens in your app and the queries each one needs. The schema falls out of that list.

If you cannot answer 'which query returns this view?' for every screen, stop and write it down. Most schema pain in Firestore is really query pain wearing a costume.

Patterns that scale

Use root collections for entities you query across the whole app, like users, products or organizations. Use subcollections for data that only ever makes sense in the context of a parent, like messages under a chat or revisions under a document. Duplicate small, immutable fields (a username, a thumbnail URL) into related documents to avoid extra reads. Keep document size well under the 1 MB limit by splitting large arrays into a subcollection. Use composite indexes for any query with more than one where clause or an orderBy on a different field. Store timestamps as native Firestore Timestamps, never as strings, so range queries work. Model many-to-many with a join subcollection that holds just the IDs and a couple of denormalized fields. Use map fields for grouped scalars, not for unbounded lists. Add a schemaVersion field on day one, you will thank yourself the first time you migrate.

Anti-patterns to avoid

Don't put unbounded arrays on a document, like every comment on a post; you will hit the 1 MB ceiling and every read pays for data you didn't want. Don't model a feed by querying every user's posts subcollection in a fan-in; build a denormalized feed collection instead. Don't rely on collectionGroup queries as a substitute for thinking about your schema, they work but they bypass the parent-scoped security rules people expect.

How a Firestore GUI helps

Schema drift is the silent killer of NoSQL projects. FireSheets shows you the actual fields and types present in a collection, not the ones you meant to have. When you see three different shapes of the same document, that's the moment to add a migration. The schema view also exports to SQL, which is handy for handing a contract to a new backend engineer.

A simple checklist

List the queries first. Pick root vs subcollection per entity. Denormalize the small, immutable bits. Add composite indexes before you need them. Cap document size. Version the schema. Review the schema view in your Firestore GUI once a sprint. Do that and the database stops being the thing you worry about.