Realtime database pricing ambiguity

[Michael Leonard]

Hi

I'm building a realtime web app and would like to double check I understand how the Blaze pricing works for the realtime database. I've tried googling but couldn't find a really clear pricing example to clear up the following ambiguity.

The pricing page says Blaze pricing is:

$5 per GB for "GB Stored" and $1 per GB for "GB downloaded".

My confusion is related to the meaning of "GB Stored". Does the $5 per GB for "GB Stored" mean...

(a) that for every GB uploaded to the realtime database, the cost is $5. [and then there is no storage cost, just upload and download costs]

(b) that the cost of 1GB of data stored for 1 month is $5. [if so is it prorated?... so storing 1GB for just 1 day is therefore approx 1/31 of $5 = approx 16 cents]

(c) neither a nor b (please elaborate!)

Toy pricing example that's close to my use case:

- Say I have a todo app used by 3 users (A, B and C). The app synchronizes todos between all three users. 

- User A adds 1MB of todos to a notes list using .ref().child("/notes/ListID").push(). User B and User C do the same.

- User A receives 2Mb of todos using the .on("child_added") callback (not the .on("value") callback). This means that 1MB of todos from user B and 1MB from user C are downloaded. User B and user C similarly receive 2Mb of todos each from the database. All users end up with 3MB of todos stored in their app. 

- User A later logs in from another machine and so all 3MB of todos are downloaded.

- User A then opts to delete the entire list so "/notes/ListID" is removed from firebase. Nothing else is stored in firebase in this toy example, and user A does this exactly 24 hours after the 3MB were originally uploaded.

Which is the correct way to cost this scenario...

Under option (a) the cost would be:

- 1/1000 for conversion from GB to MB * [(3 users * 1MB uploaded * $5) + (3 users * 2MB downloaded * $1) + (1 user * 3MB redownloaded * $1) + (no cost for the delete)]

= 1/1000 * [15 + 6 + 3] = 1/1000 * 24 = 2.4 cents

Under option (b) the cost would be:

- 1/1000 for conversion from GB to MB * [(3 users * 1MB stored for 1 day which is 16 cents) + (3 users * 2MB downloaded * $1) + (1 user * 3MB redownloaded * $1) + (no cost for the delete)]

= 1/1000 * [0.48 + 6 + 3] = 1/1000 * 9.48 = 0.9 cents

Thanks so much in advance! My use case (translated into the todo list world) is to have thousands of groups of users, with each group having a single group-list synchronized between them so that they can each add and share hundreds of todo items. I'm evaluating using the realtime database and need to make sure I can predict the costs of this for various numbers of users and payload sizes (and durations of storage periods if option (b) is true).

Thanks again for the help! Loving playing with firebase so far!

Michael

[Tom Larkworthy]

Hi Michael, 

Incoming network is not charged. The GB stored cost is the data that is at rest in the Firebase Database, prorated i.e. b). It costs to read that data through outgoing network. We try to minimize network cost, so if you set indexes, and access only relevant data via well bounded queries, you can minimize network costs significantly (e.g. don't get all todo items on a giant list if the user is only manipulating the first 10 in the UI). 

Hope that helps

--
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-talk+unsubscribe@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/70168b03-aeb4-494c-9657-470e134b6d2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Leonard]

 Hi Tom. Thanks for the quick and helpful reply. To answer your question - yes that helps tremendously, thank you!

I have a follow up question I hope you don't mind:

I don't need to store my data for very long (think a game app where game state isn't needed after the game ends). So I'd like to make sure I understand how "$5 to store 1GB for 1 month" breaks down to shorter time frames and smaller file sizes.

In my mind the ideal way I would want things to be priced is something like: every second, the total file size of the entire realtime database json structure is calculated and this database size is multiplied by a per-second-per-byte price. These per-second database costs are then up for the entire month and I'm billed, rounded up to the nearest cent I guess.

My calculation of this magic per-second-per-byte price is:

 $5 * (1 / 2^30 to convert from GB to bytes) / (number of seconds in a month which is 60 seconds * 60 mins * 24 hours * 365/12 days in a month)).

 ie 5 / (2^30) / (60 * 60 * 24 * 365 / 12) = 1.77 * 10^(-15) dollars per kilobyte per second.

What I'm really trying to get to is a per-upload cost... so that if I upload e.g. a 100kb object and store it for 3 hours then I can fairly accurately predict the cost: in this case 100 * 3 * 60 * 1.77 * 10^(-15) dollars.

Am I anywhere close to how the pricing works? Perhaps I'm way off and things work differently? Or maybe I'm close but the time or file size granularity is different?

Thanks so much for taking the time to help I really appreciate it.

Mike

PS My math degree background clearly makes me focus a lot on the details so sorry about that! I'm excited to use firebase and just want to make sure I have a handle on the pricing as the app scales.

 

[Tom Larkworthy]

Yes it works like you said but coarser. A snapshot is taken every 6 hours and sized, which corresponds to the storage usage dashboard's data points. We might might change the sampling details but we are essentially computing byte.seconds of consumption.

--

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-talk+unsubscribe@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/6378b16d-5f72-4fc7-8579-2d6d164c4939%40googlegroups.com.

[Michael Leonard]

Fantastic that's really helpful thanks very much.

On Saturday, November 12, 2016 at 4:59:37 AM UTC, Tom Larkworthy wrote:

Yes it works like you said but coarser. A snapshot is taken every 6 hours and sized, which corresponds to the storage usage dashboard's data points. We might might change the sampling details but we are essentially computing byte.seconds of consumption.

On Nov 11, 2016 5:46 PM, "Michael Leonard" <emailm...@gmail.com> wrote:

 Hi Tom. Thanks for the quick and helpful reply. To answer your question - yes that helps tremendously, thank you!

I have a follow up question I hope you don't mind:

I don't need to store my data for very long (think a game app where game state isn't needed after the game ends). So I'd like to make sure I understand how "$5 to store 1GB for 1 month" breaks down to shorter time frames and smaller file sizes.

In my mind the ideal way I would want things to be priced is something like: every second, the total file size of the entire realtime database json structure is calculated and this database size is multiplied by a per-second-per-byte price. These per-second database costs are then up for the entire month and I'm billed, rounded up to the nearest cent I guess.

My calculation of this magic per-second-per-byte price is:

 $5 * (1 / 2^30 to convert from GB to bytes) / (number of seconds in a month which is 60 seconds * 60 mins * 24 hours * 365/12 days in a month)).

 ie 5 / (2^30) / (60 * 60 * 24 * 365 / 12) = 1.77 * 10^(-15) dollars per kilobyte per second.

What I'm really trying to get to is a per-upload cost... so that if I upload e.g. a 100kb object and store it for 3 hours then I can fairly accurately predict the cost: in this case 100 * 3 * 60 * 1.77 * 10^(-15) dollars.

Am I anywhere close to how the pricing works? Perhaps I'm way off and things work differently? Or maybe I'm close but the time or file size granularity is different?

Thanks so much for taking the time to help I really appreciate it.

Mike

PS My math degree background clearly makes me focus a lot on the details so sorry about that! I'm excited to use firebase and just want to make sure I have a handle on the pricing as the app scales.

 

--
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.