Firebase Firestore Standard
Provision Firestore Standard Edition, write security rules, and integrate the Firestore SDK with correct indexes and query patterns.
Overview
firebase-firestore-standard is an agent skill most often used in Build (also Ship security) that guides Firestore Standard provisioning, security rules, SDK usage, and indexes.
Install
npx skills add https://github.com/firebase/agent-skills --skill firebase-firestore-standardWhat is this skill?
- End-to-end path: provisioning, security rules, SDK usage, and indexes reference
- Split reference docs for provisioning, security_rules, web_sdk_usage, and indexes
- Explains single-field vs composite indexes and query performance vs database size
- Compatible with Firebase CLI via `npx -y firebase-tools@latest` without hard-requiring global install
- Standard Edition focus with automatic single-field indexing called out
- Reference split across provisioning, security_rules, web_sdk_usage, and indexes modules
- Documents automatic single-field indexes in Standard Edition
Adoption & trust: 36.7k installs on skills.sh; 345 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a document database on Firebase but lack a structured path from project provisioning to rules-safe queries and index-backed reads.
Who is it for?
Builders adding or hardening Firestore in web or multi-platform Firebase apps who want official edition-specific guidance in one skill.
Skip if: Firestore Enterprise-only features, pure Realtime Database workloads, or AI Logic setup—use sibling Firebase skills instead.
When should I use this skill?
User needs help setting up Firestore Standard, writing security rules, or using the Firestore SDK.
What do I get? / Deliverables
You get pointed to the right reference modules for provision, rules, web SDK patterns, and index design so client queries stay permitted and performant.
- Provisioned Firestore instance guidance
- Security rules and index strategy aligned to queries
- SDK integration pointers for target platform
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build/backend is the primary shelf for database setup, rules, and application SDK usage across web and other platforms. Backend captures datastore provisioning and server-adjacent security rules rather than marketing or ship-time perf tuning alone.
Where it fits
Provision Firestore and wire web modular SDK for a new indie SaaS dashboard.
Harden rules before shipping user-generated content stored in collections.
Add composite indexes after new query patterns appear in production traffic.
How it compares
Firestore-focused depth skill, not a generic SQL migration or non-Firebase NoSQL tutorial.
Common Questions / FAQ
Who is firebase-firestore-standard for?
Solo developers and small teams using Firebase who need Standard Edition Firestore setup, security rules, and SDK integration help.
When should I use firebase-firestore-standard?
During Build for provisioning and SDK work; during Ship security subphase when drafting or tightening Firestore rules; whenever the user asks for Firestore indexes or query support tables.
Is firebase-firestore-standard safe to install?
It covers security rules and deployment flows—review the Security Audits panel on this page and test rules in staging before exposing production data.
SKILL.md
READMESKILL.md - Firebase Firestore Standard
# Firestore Standard Edition This skill provides a complete guide for getting started with Cloud Firestore Standard Edition, including provisioning, securing, and integrating it into your application. ## Provisioning To set up Cloud Firestore in your Firebase project and local environment, see [provisioning.md](references/provisioning.md). ## Security Rules For guidance on writing and deploying Firestore Security Rules to protect your data, see [security_rules.md](references/security_rules.md). ## SDK Usage To learn how to use Cloud Firestore in your application code, choose your platform: * **Web (Modular SDK)**: [web_sdk_usage.md](references/web_sdk_usage.md) ## Indexes For checking index types, query support tables, and best practices, see [indexes.md](references/indexes.md). # Firestore Indexes Reference Indexes allow Firestore to ensure that query performance depends on the size of the result set, not the size of the database. ## Index Types ### Single-Field Indexes In Standard Edition, Firestore **automatically creates** a single-field index for every field in a document (and subfields in maps). * **Support**: Simple equality queries (`==`) and single-field range/sort queries (`<`, `<=`, `orderBy`). * **Behavior**: You generally don't need to manage these unless you want to *exempt* a field. ### Composite Indexes A composite index stores a sorted mapping of all documents based on an ordered list of fields. * **Support**: Complex queries that filter or sort by **multiple fields**. * **Creation**: These are **NOT** automatically created. You must define them manually or via the console/CLI. ## Automatic vs. Manual Management ### What is Automatic? * Indexes for simple queries. * Merging of single-field indexes for multiple equality filters (e.g., `where("state", "==", "CA").where("country", "==", "USA")`). ### When Do I Need to Act? If you attempt a query that requires a composite index, the SDK will throw an error containing a **direct link** to the Firebase Console to create that specific index. **Example Error:** > "The query requires an index. You can create it here: https://console.firebase.google.com/project/..." ## Query Support Examples | Query Type | Index Required | | :--- | :--- | | **Simple Equality**<br>`where("a", "==", 1)` | Automatic (Single-Field) | | **Simple Range/Sort**<br>`where("a", ">", 1).orderBy("a")` | Automatic (Single-Field) | | **Multiple Equality**<br>`where("a", "==", 1).where("b", "==", 2)` | Automatic (Merged Single-Field) | | **Equality + Range/Sort**<br>`where("a", "==", 1).where("b", ">", 2)` | **Composite Index** | | **Multiple Ranges**<br>`where("a", ">", 1).where("b", ">", 2)` | **Composite Index** (and technically limited query support) | | **Array Contains + Equality**<br>`where("tags", "array-contains", "news").where("active", "==", true)` | **Composite Index** | ## Best Practices & Exemptions You can **exempt** fields from automatic indexing to save storage or strictly enforce write limits. ### 1. High Write Rates (Sequential Values) * **Problem**: Indexing fields that increase sequentially (like `timestamp`) limits the write rate to ~500 writes/second per collection. * **Solution**: If you don't query on this field, **exempt** it from simple indexing. ### 2. Large String/Map/Array Fields * **Problem**: Indexing limits (40k entries per doc). Indexing large blobs wastes storage. * **Solution**: Exempt large text blobs or huge arrays if they aren't used for filtering. ### 3. TTL Fields *