firebase-scalability

Guides Firestore schema design, security rules, indexing, and query optimization for scale.

Updated Mar 9, 2026
One-click install
npx skills add https://github.com/yunior123/origna_gta_firebase --skill firebase-scalability-yunior123
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: firebase-scalability
Source: https://github.com/yunior123/origna_gta_firebase/tree/main/.claude/skills/firebase-scalability
Command: npx skills add https://github.com/yunior123/origna_gta_firebase --skill firebase-scalability-yunior123

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Firestore applications often hit scaling walls: bloated documents, runaway read costs, slow security rules, and race conditions in checkout flows. This Skill provides concrete patterns for NoSQL data modeling, indexing, security rules, and backend efficiency so your Firebase architecture holds up under growth. ## Core Features & Use Cases - Data Modeling Guidance: Decide between subcollections and arrays based on growth patterns, respecting the 1MB document limit and read-cost tradeoffs. - Security Rules Optimization: Write low-latency rules using custom claims, minimal get()/exists() calls, and strict field type and size validation. - Adversarial Backend Design: Prevent price tampering with server-side re-fetching and eliminate race conditions with transactional inventory updates. - Use Case: When designing a marketplace checkout flow, apply this Skill to model orders as subcollections, enforce idempotent Cloud Functions, and validate prices server-side before payment capture. ## Quick Start Review my Firestore schema and security rules for scalability issues and suggest improvements for indexes, subcollections, and server-side validation.

Frequently Asked Questions about firebase-scalability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I model Firestore data for scale?▼

Use subcollections for unbounded data like comments, transactions, and logs, and arrays only for small bounded sets under roughly 50-100 items. Documents have a 1MB limit, and large documents cost more to read and parse than many small ones.

When should I use subcollections vs arrays in Firestore?▼

Use subcollections when a collection can grow indefinitely, such as user transactions or order history. Use arrays for small, bounded sets like product tags or user addresses, keeping them under about 100 items to avoid array bloat.

How do I reduce latency in Firestore security rules?▼

Use rules_version 2, minimize get() and exists() calls to under 10 per request, and store roles in custom claims like request.auth.token.role to save one document read per request. Also validate every field's type and size directly in the rules.

How do I prevent price tampering in a Firebase checkout flow?▼

The backend must re-fetch prices from Firestore during checkout rather than trusting client-supplied values. Combine this with transactional stock updates using @firestore.transactional and idempotency keys to prevent race conditions and duplicate charges.

What are Firestore composite index limits?▼

Firestore allows a maximum of 200 composite indexes per database. Define them in firestore.indexes.json, avoid over-indexing, and favor single-field indexes combined with 'in' queries where possible to reduce the total index count.

How do I reduce Cloud Functions cold starts?▼

Move heavy imports inside the function body so they load only when needed. Use asyncio.gather in Python or Future.wait in Dart for parallel data fetching, and enforce idempotency with transaction keys or Stripe idempotency headers.