Firebase Functions GB downloaded

[Vishal Desai]

If we write query to get realtime db data, does it count toward Blaze GB downloaded quota which is $1/1GB?

[Tyler Rockwood]

Yes, all outgoing bandwidth from your database is billed, including using the console. See https://firebase.google.com/docs/database/usage/billing for more info about our billing for the Realtime Database.

[Vikas Ranjan]

Does GB downloaded include the size of two files downloaded upon each Firebase connection? - firebase-app.js(5.6kb) and firebase-database.js(41.4kb)
In my use case, Firebase database used for any read/write only 10% times of all page-loads. So if the above files are accounted in the consumption then I might be wasting 90% of my spending on Firebase without any value.

Is there any way I can analyze the data downloaded for each connection to have a transparent look at my consumption? I have seen my data downloaded jump over 5x while everything else remained constant.

[Tyler Rockwood]

Those files are not downloaded from the realtime database so no.

You can analyze it (as mentioned in the link) by using our profiler,  ALTHOUGH please note this is an estimate that doesn't include many factors: https://firebase.google.com/docs/database/usage/profile

The usage doc explains this.

[Vikas Ranjan]

Thanks a lot, Tyler. I have used Database profiler and got some detailed insights. 

I have a follow-up question - Do uploaded bytes contribute to the Firebase bill? I have seen at some place that "incoming network are not charged", just wanted to clarify.

[Tyler Rockwood]

Incoming bandwidth is not charged. HOWEVER! Any incoming bandwidth (write) is going to cause outgoing bandwidth on the SSL handshake and the bytes needed to send back the HTTP header/or websocket frame. Also note if you're using rest the payload written is in the responses unless you use print=silent as a query parameter.

[Tyler Rockwood]

Ivan,

To answer your question, we don't charge for incoming bandwidth. We do charge any outgoing bandwidth on the connection, to understand more about out billing see: https://firebase.google.com/docs/database/usage/billing

Also to scale write we suggest batch writes in multi-location updates. The REST documentation has the best information on how to batch writes: https://firebase.google.com/docs/database/rest/save-data#section-update

Hope that helps.

-Tyler

On Wednesday, August 16, 2017 at 9:06:42 PM UTC-7, Ivan Nincic wrote:

I have related question. 

I don’t mind paying for extra bandwidth cost to read all replicated data, however I do not understand why Firebase users would pay for writing replicated info (both in therms of perf and cost).

Specifically I am referring to Firebase (and general NoSQL) advice of ‘write-to-many’ pattern (e.g. as recommended https://firebase.google.com/docs/database/web/read-and-write#update_specific_fields and many other places).

Our benchmarks indicate this results in significant bandwidth costs on ‘write’? Are we missing something? 

Can we use Google Cloud Functions to write to multiple-paths without incurring extra bandwidth costs? Given your network infrastructure we assume that bandwidth btw Cloud Functions and RT DB “should not” incur a ‘significant’ bandwidth cost? Would this not be a differentitor for you (as opposed to using lambdas etc)?

Alternatively is there any other way for us to write to multiple paths in a single call (a simple implementation on your end may be a Cloud Function collocated with RB DB) ? 

The bottom line is FB recommends  ‘write-to-many' pattern, but can this operation be implemented in scalble manner (both in terms of perf and cost)?