Is Spanner Really That Expensive? The Surprising Break-Even Point with Firestore

This content originally appeared on DEV Community and was authored by apstndb

Note from the author: This article was originally written in Japanese for the community in Japan. The original version can be found here. Believing the content could be valuable to a global audience, I’ve translated it into English. The translation was performed with the assistance of Google’s Gemini 2.5 Pro. I have reviewed and edited the translation for accuracy and clarity.

A recent article on the tech blog of KAUCHE, a Japanese e-commerce company, “Firestore → Cloud Spanner DB Cost Reduction of 93%! The Complete Record of a Year-Long Zero-Downtime Migration” (in Japanese), has been making waves.
Anyone who has used Firestore (or its predecessor, Datastore) knows that beyond a certain usage level, it can become more expensive than Spanner. However, database migrations are notoriously difficult, so many users likely remain on Firestore despite the cost. The fact that KAUCHE accomplished a zero-downtime migration from Firestore to Spanner is truly impressive.

Interestingly, looking at the reactions to this article, I noticed a common thread of surprise that migrating from Firestore to Spanner could actually reduce costs.

https://x.com/search?q=https%3A%2F%2Fzenn.dev%2Fkauche%2Farticles%2F1e733da3748ee1&src=typed_query&f=live

Why does this surprise exist, when there are options within Google Cloud like Firestore that can become significantly more expensive than Spanner? I believe it’s because Firestore offers a generous daily free tier, making it easy to start small, while Spanner has no free tier and is plagued by a persistent preconception that it is “expensive.”

This misconception can hinder optimal technology choices, leading to lost opportunities for developers, businesses, and even Google. It can cause tangible financial harm and create significant technical debt by forcing a difficult database migration in the future.

Google itself has been trying to dispel this myth, publishing articles like “Cloud Spanner myths busted” and holding sessions like the “Spanner: Database Unlimited Series” based on it.

Why did this “expensive” image stick?
As Google’s article mentions, it’s likely due to outdated impressions:

• High minimum cost for production instances with an SLA: It used to require a minimum of 3 nodes, costing around $2,000/month even in the cheapest us-central1 region.
  • In September 2019, this was reduced to 1 node with an SLA, cutting the cost by two-thirds.
  • With granular instance sizing (GA in May 2022), it became possible to get an SLA with just 0.1 nodes (100 PUs), reducing the cost by another factor of 10.
  • The cost is now comparable to a Cloud SQL db-g1-small instance with an HA configuration.
• No free development environment: Since it’s not open-source, development environments incurred similar costs.
  • This has been addressed with the official Spanner emulator (GA in July 2020) and free trial instances (GA in September 2022).

Despite these efforts, the message may not have fully resonated without concrete numbers. And comparing it to competitor products is often frowned upon.

So, I thought, why not do a quantitative comparison between Google Cloud’s own database offerings? There seems to be value in making that public.

Firestore vs. Spanner: A Price Comparison

In this article, I’ll perform a price comparison between Firestore and Spanner, inspired by the cost issues highlighted by KAUCHE’s experience.

A few notes on the comparison:

• This is a simplified comparison focusing only on Firestore and Spanner among Google Cloud’s database offerings.
  • I’ll assume Firestore is used as a backend database. The differences between Native mode and Datastore mode are not critical to the conclusion.
  • I will not compare them with services from other cloud providers.
  • This is not a general SQL vs. NoSQL or SQL vs. Distributed SQL comparison.
• The comparison is based solely on information from the official documentation.
  • No load testing is involved.
• Since a key goal is to raise awareness, I will be direct about the cost challenges of Firestore, based on the data.

Extracting Relevant Values from Official Docs

• All values are as of July 9, 2025.
• The region is standardized to asia-northeast1 (Tokyo).
• Currency is kept in USD to avoid exchange rate fluctuations.
• Committed Use Discounts (CUDs) are omitted as they are the same for both Firestore and Spanner (20% for 1 year, 40% for 3 years) and don’t affect the relative comparison.
• Network egress fees are the same for both and are not included in this comparison’s scope, though they can affect the total cost.

Firestore

Firestore is entirely pay-as-you-go, so all the pricing information is on one page.

• Firestore pricing
• Firestore in Datastore mode pricing

Native mode and Datastore mode have slightly different terminology but the same pricing structure. I’ll use the newer Native mode terms.

Note: Firestore Native mode doesn’t have “small operations.” Index entry reads and aggregation queries are counted as one document read per 1,000 entries. Also, the Firestore editions overview states that the Standard edition uses Hybrid storage (SSD & HDD).

Spanner

Spanner is billed based on provisioned capacity in Processing Units (PUs). We need to look at two pages:

• Spanner pricing
• Performance overview

Compute Capacity

The features in the Standard edition are sufficient for this comparison, so I’ll focus on that.

Database Storage

I’ll focus on SSD storage for this comparison.

Estimated Throughput from Docs

While database performance typically requires workload-specific benchmarks, Spanner provides estimated throughput for simple workloads in its documentation. This is a reasonable approximation for a comparison with Firestore, which is primarily used for key-based reads and writes without complex queries.

Read guidance is given per region (because reads can be served from any read-write or read-only region), while write guidance is for the entire configuration. Read guidance assumes you’re reading single rows of 1KB. Write guidance assumes that you’re writing single rows at 1KB of data per row.

Here is the estimated throughput for a regional configuration like asia-northeast1:

Performance for regional configurations
Each 1,000 processing units (1 node) of compute capacity can provide the following peak performance (at 100% CPU) in a regional instance configuration:

I’ll use the highlighted SSD values.

(Note) This catalog spec has improved significantly. An announcement on October 11, 2023 detailed Performance and storage improvements, boosting typical throughput by 1.5x for both reads and writes and increasing the storage limit by 2.5x. If you want to verify these numbers, you can check the YCSB benchmark results in “Benchmarking Spanner’s cost-performance for key-value workloads“.

Spanner’s Minimum Configuration: Price and Throughput

A Spanner instance can be created with as little as 100 Processing Units (PUs), which is 0.1 nodes. This configuration is production-ready and comes with an SLA. Here are the adjusted numbers for this minimum setup:

This is at 100% CPU utilization. However, the official documentation (Alerts for high CPU utilization) recommends keeping CPU utilization for high-priority tasks below 65% for regional instances. I will factor this into the comparison.

Why 65%? While not explicitly stated, this is likely to maintain service levels during a zonal failure. A regional Spanner instance has R/W replicas in three zones. If one zone goes down, you lose 1/3 of your capacity. To handle the same load, the remaining 2/3 of capacity (approx. 67%) must suffice. Staying at 65% ensures that a zone failure won’t push CPU usage over 100%. This logic also explains the 45% recommendation for dual/multi-region instances, which have replicas in two R/W regions (losing one leaves 50% capacity).

The Comparison

Let’s find the break-even point between the minimum Spanner configuration and Firestore.

• I’ll assume a steady workload of either 1KB reads only or 1KB writes only.
• I’ll assume the schema is well-designed to achieve theoretical performance.
• I’ll include Firestore’s daily free tier.
• I’ll factor in Spanner’s 65% recommended CPU utilization.

The break-even point is where Firestore Cost = Spanner Cost. We can find the number of daily operations, x, with the formula:

Variables:

• $x$ = Number of operations per day (what we want to find)
• FfreeF_{\text{free}}Ffree​ = Firestore free tier operations (Reads: 50,000, Writes: 20,000)
• PfirestoreP_{\text{firestore}}Pfirestore​ = Firestore price per operation (Read: \$0.00000038/op, Write: \$0.00000115/op)
• CspannerC_{\text{spanner}}Cspanner​ = Spanner daily cost (100 PU = \$0.117/hr * 24h = \$2.808/day)

To be more precise: The above formula is a simplification. To be perfectly accurate, you need to account for Firestore’s 100,000-operation billing increments. The break-even point x is more accurately calculated with the following formula:

Here are the results, visualized with graphs. The plots are continuous approximations for simplicity, but the break-even point calculations are precise.

Reads

The break-even point for reads is 7,450,000 reads/day, which is about 86 reads/sec.
This is only 3.8% of the peak performance of a 100 PU Spanner instance.

If you utilize Spanner up to the recommended 65% of its theoretical throughput, it becomes 17 times cheaper than Firestore. This clearly shows how sticking with Firestore at scale can lead to massive cost increases.

Writes

The break-even point for writes is 2,520,000 writes/day, which is about 29 writes/sec.
This is about 8.1% of the peak performance of a 100 PU Spanner instance.

If you utilize Spanner up to the recommended 65% of its throughput, it is 8 times cheaper than Firestore.

Storage

A direct storage cost comparison is difficult because Firestore uses hybrid storage. However, we can get a rough idea. A 100 PU Spanner instance has a storage limit of 1024 GiB.

While Spanner’s storage unit price is higher, the difference is not the dominant factor. In a scenario where you are maxing out the read/write capacity of a 100 PU instance, the daily cost difference for operations is in the tens of dollars, which far outweighs the storage cost difference.

Analysis

The calculations show that while Spanner isn’t always cheaper, it becomes significantly more cost-effective than Firestore beyond a certain scale. This isn’t surprising. Both databases offer strong consistency and high availability through geographic distribution, making them comparable services. The main differences are the data model and the billing model.

Generally, provisioned capacity is discounted relative to on-demand, pay-per-operation pricing.

In fact, Firestore and Spanner are more than just similar. It has been suggested since Firestore’s launch, and later confirmed in Google research papers, that Firestore is implemented on top of Spanner. The architecture of Firestore is detailed in the “Firestore: The NoSQL Serverless Database for the Application Developer“ paper, and its implementation on Spanner is further described in “Transparent Migration of Datastore to Firestore“.

In other words, Firestore is a high-value managed service that abstracts away complexities like query planning and capacity management by offering Spanner’s powerful infrastructure on a multi-tenant basis, which provides an easy, free-to-start experience. The price difference at scale can be seen as the cost of this abstraction.

To Anyone Considering Firestore

If you’re considering Firestore for your backend, keep these points in mind:

• Firestore’s cost advantage is limited to a relatively narrow range for a horizontally scaling database: from the free tier up to a few million operations per day.
• Be aware that costs will scale with number of users × operations per user.
• If your service has a fixed number of users (e.g., an internal tool), Firestore is likely a safe choice. Otherwise, always evaluate the possibility that Spanner will become cheaper.
• If your service can justify the monthly cost of a 100 PU Spanner instance (approx. $85/month), choosing Spanner from the start might give you more peace of mind.

For real-time database use cases where clients connect directly, Firestore is often the right choice. Building the real-time capabilities yourself on top of Spanner would be a massive undertaking. In that case, the comparison should be against services like Firebase Realtime Database.

Conclusion

Firestore is often perceived as a cheap database, suitable for personal and small-scale projects. However, this analysis shows that the cost break-even point with Spanner’s minimum configuration (approx. $85/month) is reached at less than 10% of that Spanner instance’s capacity.

Beyond that point, Spanner becomes dramatically cheaper: up to 17 times cheaper for reads and 8 times cheaper for writes. An $85/month cost is not significantly higher than the minimum cost for other HA database configurations on Google Cloud.

So, is Spanner still “expensive”? If you hear someone say that, ask them under what conditions, compared to what, and which specific SKU they are talking about.

Appendix: Firestore Enterprise Edition

For those who think Firestore becomes too expensive, you might want to look at the new Firestore Enterprise edition, announced at Cloud Next 2025 and currently in preview.

While it currently only offers MongoDB compatibility, the Firestore editions overview states that Native mode support is planned for the future.

According to the Firestore Enterprise edition pricing, it has a pricing structure geared towards larger-scale users compared to the Standard edition.

Note the change in billing unit from 100K to 1M operations. This makes read/write operations cheaper for small documents. However, units are calculated in 4 KiB increments for reads and 1 KiB for writes. This means documents larger than 24KB (for reads) or 4KB (for writes) could become more expensive than in the Standard edition.

Even with this new pricing, the fundamental trend of becoming more expensive than Spanner at scale seems to persist. It would be ideal if users who start small with Firestore didn’t have to regret their choice later. A future where Firestore offers a provisioned capacity model, similar to Spanner, would be a welcome development, combining the ease of getting started with the cost-efficiency of Spanner at scale.

This content originally appeared on DEV Community and was authored by apstndb