Firestore Pricing, developer's thoughts?

2,303 views
Skip to first unread message

Dr.Z

unread,
Feb 24, 2018, 4:07:56 PM2/24/18
to Firebase Google Group
Hello, the only reason i'm writing this post is because i'm amazed and want to stick to Firebase, the new secure dynamic databases are obviously the future for Apps, webs and non ultra-low latency games. Firebase Real-Time database is really good choice for start-ups but very bad for highly scalable demands. On the other hand, Firestore is super scalable. So I wanted to know the developers' thoughts on costs after beta? Please see this simple comparison


Read = Ability to read data that is <1kb in size.
Write = Ability to write data that is <1kb in size.


Bear in mind that this only the specific service cost.




```

Azure Cosmos DB (<10ms read, <15ms writes):

1B reads = 45$.

500M writes = 112$.



AWS Dynamodb:

1B reads = almost 34$.

500M writes = 90$ .



Firebase Firestore:

1B reads = 600$.

500M writes = 900$.

```


Although it might seem Firebase is super expensive, but for example in Azure they charge [Stored User/Month (0.0011$/month)], [Auth/Month (0.0028$)]. Whereas Firebase does this for free, so the comparison isn't for the entire service AWS vs Azure vs Firebase, but specific services that are mentioned above.


So I'd like to know what is the firebase team's thoughts on Firestore pricing after beta?

Samuel Stern

unread,
Feb 26, 2018, 12:33:26 PM2/26/18
to fireba...@googlegroups.com
Hi there,

Right now we don't have any plans to change pricing as a result of "graduating" Beta.  That's not to say the prices will never change, but I just want to set expectations correctly.  The main thing that will change at that point is scalability limits, you can expect to see higher write QPS and more realtime connections supported in Cloud Firestore as the product matures.

As you mentioned, when you use Cloud Firestore you'll likely see cost savings in other areas of your infrastructure.  For instance Cloud Firestore is designed to be accessed directly from a mobile app, which means you don't need to pay for an intermediate server to proxy requests and check authentication, etc.   It's also 100% managed and auto-scaling so there should be zero "database administration" time cost.

In the end, you have to make the decision that's right for your app.  If your app will benefit from the real-time synchronization, offline readiness, and direct client access that Firestore provides then you'll probably be happy to pay a little more for it.  If you don't need any of that, you may be better off with another database product (Google or otherwise).

- Sam



--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/98c6827f-8c16-4137-8f73-093e7c61edc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dan McGrath

unread,
Feb 27, 2018, 4:39:51 PM2/27/18
to Firebase Google Group
Adding to Sam's answer as I'm responsible for pricing and catching up from some vacation.

There is a lot of nuance to compare pricing then is mentioned in the original question. While it is relatively easy to map what your costs will be on Cloud Firestore if you understand user actions, etc, my experience has shown that there are many aspects to pricing of other systems such as some you mentioned that are not understood until you read the fine print on how pricing is done as well as operational details of those systems.

The comparison is is essentially comparing averages (e.g. x Billion reads & writes over a month), which actually works when costing out Cloud Firestore, but not for other systems that charge based on peak usage.

As an example, experience of working with thousands of customers show average usage compared to peak can range from 10% to 50%. Cloud Firestore also doesn't 'cost' additional throughput units for indexes, whereas other systems will count each index as an additional 'write' against write through - Factor in 5-10 indexes per document and it quickly becomes a major cost factor.

Additionally, these systems are fundamentally different in that Cloud Firestore gives you Multi-Region replication across multiple data centers out of the box (compared to Regional & Zonal alternatives), offer features such as multi-documentation transactions and richer querying (which can involve more data duplication and server side code, thus increasing effective costs, compared to some alternatives).

I've given examples of just some of the considerations of cost that can be easy to overlook when comparing. Ultimately, as Sam mentions, you'll understand your apps requirements, access patterns, and how Cloud Firestore can reduce the amount of infrastructure you'll need to build maintain.

I hope that helps,
Dan
Reply all
Reply to author
Forward
0 new messages