Firestore Cost Optimization: The Essential Guide

Google Cloud Firestore provides serverless NoSQL document storage with real-time synchronization and offline support, making it popular for mobile and web applications. However, costs accumulate from multiple dimensions: document reads and writes, index operations, storage for documents and indexes, network egress, and backup retention.

This guide addresses optimization strategies to reduce Firestore costs, with practical tips and examples to save significantly without harming application functionality.

How Firestore Pricing Works

Firestore charges accumulate across five primary dimensions. Operations — document reads, writes, and deletes — form the baseline cost structure. Standard edition pricing varies by location; in us-central1, Firestore charges $0.03 per 100,000 document reads, $0.09 per 100,000 writes, and $0.01 per 100,000 deletes. Enterprise edition uses Read Units and Write Units; in us-central1, pricing is $0.05 per million Read Units and $0.26 per million Write Units, with separate charges for real-time update units.

Index operations add overhead in Standard edition. Queries with up to one range field are exempt; for other applicable queries, Firestore generally charges one read operation for each batch of up to 1,000 index entries read.

Storage starts at $0.15/GB/month in us-central1, including both document storage and index storage. Over-indexed collections storing unnecessary composite indexes or exempting too few fields from automatic indexing accumulate storage charges proportional to index breadth. Organizations running large collections with dozens of indexed fields per document often discover index storage exceeds document storage costs.

Network egress charges apply when data transfers between Firestore and clients or services outside Google Cloud's network. Cross-region traffic costs $0.08-0.12/GB depending on destination. Applications serving Firestore data to users globally or integrating with external APIs incur egress fees proportional to data volume transferred.

Backup and recovery features carry additional charges. Automated backups cost based on storage consumed. Point-in-time recovery (PITR) adds ongoing storage costs for retained transaction logs. Time-to-live (TTL) delete operations are billed as standard deletes despite being automated.

Regional versus multi-region Firestore instances present cost-performance tradeoffs. Multi-region instances provide higher availability and lower latency for globally distributed users but cost more than regional instances. Organizations without global distribution requirements can reduce costs 30-40% by selecting regional deployment.

Optimize Query and Read Costs

Query optimization represents the highest-impact cost reduction lever. Inefficient queries scanning unnecessary documents or retrieving unneeded fields multiply read operation costs.

Limiting documents returned through pagination and limit() clauses prevents over-fetching. Implementing pagination with reasonable page sizes (10-50 documents) and using query cursors rather than offsets reduces costs. Offset-based pagination forces Firestore to scan and skip offset documents, billing for those scans. Cursor-based pagination resumes from specific document positions without scanning.

Field selection reduces data transfer, particularly in Enterprise where result document size impacts Read Unit consumption. Using select() projections to retrieve specific fields rather than entire documents cuts result sizes for documents with many fields.

Query filters and indexes interact to determine document scan volume. Well-indexed queries leverage composite indexes covering filter conditions. Poorly indexed queries trigger collection scans. Firestore's Query Explain in Enterprise reveals execution plans showing document scans and index usage.

Real-time listeners require careful cost management. Initial listener attachment reads all matching documents. Subsequent changes trigger additional reads. Applications with many concurrent users maintaining listeners to large collections multiply read costs through repeated document reads.

Optimize Firestore Indexes

Index management directly impacts both storage costs and write operation overhead. Over-indexing creates unnecessary composite indexes consuming storage space and requiring updates on every document write. Under-indexing forces collection scans for queries lacking appropriate indexes.

Removing unused composite indexes eliminates wasted storage and reduces write overhead. Composite indexes created during development or experimentation often persist after the queries they supported are removed or refactored. Firestore's index management interface shows last-used timestamps for composite indexes in Enterprise edition, identifying candidates for deletion. Each removed index reduces storage costs and write amplification proportionally.

Field exemptions prevent automatic indexing of fields never used in queries. Firestore automatically indexes all document fields for equality and range queries by default. Large documents with dozens of fields storing descriptive text, large arrays, or metadata not referenced in queries waste index storage. Configuring field exemptions for these fields reduces index storage costs without impacting query performance.

Index fanout describes the number of index entries created per document write. Fields storing arrays create one index entry per array element. A document with a 100-element array field creates 100 index entries per write operation. Arrays storing tags, categories, or related IDs require indexing for array-contains queries but create substantial fanout. Limiting array sizes, splitting large arrays across multiple documents, or using alternative data structures reduces fanout and associated write costs.

Composite indexes should cover common query patterns without creating redundant indexes. Firestore requires composite indexes for queries combining multiple filters or mixing filters with sort orders. Over-specifying indexes creates unused variations. Analyzing actual query patterns through application monitoring identifies which composite indexes deliver value versus those created unnecessarily.

Covered indexes in Enterprise edition satisfy queries entirely from index data without reading documents. Queries requesting only indexed fields can be served from indexes alone, reducing Read Unit consumption. Structuring indexes to cover common read-heavy query patterns cuts costs for workloads dominated by simple lookups.

Reduce Unnecessary Read and Write Amplification

Application architecture choices often introduce read and write amplification — billing for operations beyond the minimum required.

Security Rules can trigger additional billed reads when they use get(), exists(), or getAfter() to evaluate other documents. Query requests are limited to 10 document-access calls during rules evaluation, and some repeated calls may be cached.

Transactions and batched writes increase costs proportional to transaction scope. Transactions reading documents to determine writes bill for both operations. Optimizing transaction scope to include only necessary operations reduces total counts.

Cloud Functions triggered by Firestore changes introduce cascading operations. A document write triggering a Function that performs additional Firestore operations creates amplification. Batching Function processing or moving analytics workloads elsewhere reduces function-induced amplification.

Optimize Your Firestore Data Model and Caching

Data model design determines operations required to satisfy application requests. Inefficient models requiring multiple round-trips inflate costs.

Caching frequently accessed reference data eliminates redundant Firestore reads. Configuration data, user profiles, and lookup tables accessed on every request are prime caching candidates. Application-level caches (Redis, Memcached) or client-side caching reduce Firestore operations proportional to cache hit rates.

Denormalization reduces repeated reads by embedding related data. A blog post embedding author name avoids separate reads to user documents. Denormalized schemas increase write complexity but cut read costs for read-heavy workloads.

Balance embedding versus references based on access patterns. Embed data accessed together frequently. Reference data accessed independently or updated often.

Optimize Data Lifecycle and Storage

Storage management and lifecycle policies control long-term storage costs.

Time-to-live (TTL) policies automatically delete documents after retention periods, reducing storage for ephemeral data. TTL deletes are billed as delete operations but eliminate ongoing storage costs.

Archiving cold data to Cloud Storage or BigQuery reduces Firestore storage costs. Firestore starts at $0.15/GB/month; Cloud Storage Standard costs roughly $0.02/GB/month. Historical order data accessed rarely can migrate to Cloud Storage with Firestore maintaining only recent orders.

Move Unsuitable Workloads Out of Firestore

Firestore optimizes for transactional access patterns. Workloads requiring large analytical scans cost less on specialized systems.

Analytical queries scanning collections consume excessive read operations. Exporting Firestore data to BigQuery for analytics aligns costs with access patterns. Firestore data export can run daily or continuously through Datastream. For comprehensive GCP cost monitoring across all services, unified visibility helps identify when workloads should migrate between services.

Full-text search requires specialized infrastructure. Integrating systems like Algolia or Elasticsearch for search-heavy workloads provides better performance at lower cost than forcing Firestore to serve unsuitable use cases.

Optimize Location and Network Costs

Firestore deployment location impacts both base pricing and data transfer costs. Regional versus multi-region deployment and compute colocation significantly affect total cost.

Regional Firestore instances cost less than multi-region instances while providing lower latency for regionally concentrated users. Multi-region instances replicate data across regions for high availability and global distribution but charge premiums for storage and operations. Organizations serving users primarily in one region should select regional deployment unless availability requirements justify multi-region overhead.

Co-locating compute with Firestore reduces network egress charges. Applications running on Cloud Run, Cloud Functions, or Compute Engine in the same region as Firestore avoid cross-region transfer fees. Deploying application infrastructure in us-central1 with Firestore in europe-west1 incurs egress charges on every query response. Aligning deployment regions eliminates unnecessary transfer costs.

Use Firestore Committed Use Discounts

Committed Use Discounts (CUDs) reduce Firestore operation costs for predictable workloads through advance commitment purchases. CUDs apply specifically to document operations — reads, writes, and deletes — not storage, backups, or network charges.

Firestore CUDs offer 20% discounts on 1-year commitments or 40% discounts on 3-year commitments. Firestore CUDs are spend-based commitments: you commit to a minimum hourly spend on eligible read, write, and delete operations. Usage above the committed spend continues at standard rates, while unused committed spend is still charged.

Purchase CUDs after optimizing operations, not before. Committing to current inefficient operation volumes locks in costs for wasteful patterns. Implementing query optimization, index cleanup, and read reduction strategies first maximizes CUD value by committing to genuinely necessary operation volumes rather than inflated baselines. For more information on maximizing the value of your GCP pricing discounts, check out our complete guide.

How nOps Helps Optimize Firestore Costs

If you’re looking to understand, allocate, and optimize Firestore costs, nOps was built to help.

• Unified visibility: Get all of your spending from GCP, AWS, Azure, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.
• Commitment Management: Automatically maximize discounts and minimize commitment risk across eligible cloud infrastructure surrounding your Firestore workloads. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

We’ve talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across the infrastructure supporting Firestore and the rest of your cloud environment.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo

Frequently Asked Questions