Goal
Design Firestore data models that match query patterns, permissions, and operational constraints.
When to Use
- The app uses Firestore.
- Collections and document ownership need planning.
- Security rules and queries depend on document shape.
Instructions
- Start from access patterns, not relational habits.
- Define top-level collections, document IDs, and any subcollections.
- Plan denormalization where query needs justify it.
- Call out rule-sensitive fields, counters, and aggregate patterns.
- Consult
references/firestore-patterns.mdwhen query and rule tradeoffs matter.
Constraints
- Do not mirror SQL table design mechanically.
- Avoid deep nesting unless access patterns truly require it.
- Keep rule checks cheap and document ownership obvious.
Output Format
- Collection map
- Document sketches
- Query/rule implications
- Denormalization notes
Examples
- "Design Firestore for a chat and notifications app."
- "How should we model team projects in Firestore?"