Firebase Firestore Basics
Provision Firestore, write security rules, and integrate the modular web SDK with correct indexes and query patterns.
Overview
firebase-firestore-basics is an agent skill most often used in Build (also Ship security) that guides Firestore provisioning, security rules, SDK usage, and indexing for Firebase projects.
Install
npx skills add https://github.com/firebase/agent-skills --skill firebase-firestore-basicsWhat is this skill?
- End-to-end path: provisioning, security rules, modular web SDK, and indexes
- References dedicated guides for provisioning, security_rules, web_sdk_usage, and indexes
- Explains automatic single-field indexes vs composite index requirements
- Notes Firebase CLI compatibility via `npm install -g firebase-tools`
- Query performance guidance tied to result-set size, not database size
Adoption & trust: 1.3k installs on skills.sh; 345 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need Firestore in your app but are unsure how to provision the database, lock it down with rules, and query it without index or SDK mistakes.
Who is it for?
Indie SaaS or mobile-backed products standardizing on Firebase Auth plus Firestore for realtime or document data.
Skip if: Teams committed to SQL-only stacks, or products that need only Firebase Hosting without a document database.
When should I use this skill?
When the user needs help setting up Firestore, writing security rules, or using the Firestore SDK—including indexes and query support.
What do I get? / Deliverables
You get structured steps and reference pointers for provisioned Firestore, deployed rules, working modular SDK integration, and index-aware queries.
- Provisioning checklist
- Security rules drafts
- SDK integration patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Firestore setup and SDK integration are foundational backend work during product build. Provisioning, rules, indexes, and client SDK usage are backend data-layer concerns, not launch distribution.
Where it fits
Wire the modular web SDK and collection paths after enabling Firestore in the Firebase console.
Align client queries with composite indexes before shipping multi-field filters.
Draft and deploy security rules that enforce auth.uid ownership on user documents.
Diagnose missing-index errors and adjust rules when new collections are added.
How it compares
Use as a curated Firestore onboarding path instead of scattering across disparate Firebase reference pages in chat.
Common Questions / FAQ
Who is firebase-firestore-basics for?
Solo builders and small teams shipping Firebase-backed apps who want agent help across provision, rules, SDK, and indexes in one skill.
When should I use firebase-firestore-basics?
During Build (backend) when adding Firestore, during Ship (security) when tightening rules pre-launch, and during Operate (iterate) when fixing queries or index errors.
Is firebase-firestore-basics safe to install?
Review the Security Audits panel on this Prism page; skills that touch cloud config and rules should be used with least-privilege Firebase credentials.
SKILL.md
READMESKILL.md - Firebase Firestore Basics
# Firestore Basics This skill provides a complete guide for getting started with Cloud Firestore, 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 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 * **Problem**: TTL (Time-To-Live) deletion can cause index churn. * **Sol