Firebase Costs Increased by 7,000%! is it true?

[zahid ali]

Hi,

I am creating a product which is using Firebase. Today i read this article (see link below) and it freaked me out. Me and my startup cannot afford such abrupt spike in price.

Can anyone explain what is the reality. Is this article saying truth.

https://medium.com/@contact_16315/firebase-costs-increased-by-7-000-81dc0a27271d

[Piotr Kaminski]

I'm guessing the Firebase team is busy at I/O today, but here's Andrew's public response to the post:  https://medium.com/@startupandrew/firebase-founder-here-im-very-sorry-for-the-surprise-and-frustration-experienced-by-the-poster-b0065c99f53e

    -- P.

--
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/713fa4fe-4e33-4d1c-a3c0-41c7a6d5ae7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

  Piotr Kaminski <pi...@ideanest.com>

  "That bun is dirty.  Don't eat that bun."

[Ian Barber]

Firebase DevRel here, yep Andrew's response is a great place to look. The article is right that the developer saw a spike in costs, but it was a very specific set of circumstances (very high TLS to data ratio, and previous billing not including TLS bandwidth due to an undercounting bug our side) that is unlikely to apply to you. 

Even if the high TLS usage circumstances did apply, you'd see it right away now - the unfortunate thing in the post was that the developer started using the service during a period where we weren't charging correctly, so it appeared as a big spike when the issue was fixed.

As Andrew says, we're looking at options for improving the profiler to make these kind of things more easily visible. 

Mainly though, all of us here are really sorry the developer had a bad experience: a lot of that was due to the delay in communications from our side, and we're looking at ways of improving that. 

Hopefully that gives you an idea of what happened, but happy to clarify more: we want our pricing and billing to be predictable. 

Ian 

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CANF_M5yX9NK1kd%3DVZpGg5UtANSninnuPMEug60a6SCPHk8sk5g%40mail.gmail.com.

[James Wrightson]

I read that authentication failures count against usage, is this true and if so what can be done to prevent someone from making a bot and screwing me over?

On Wednesday, 17 May 2017 18:45:18 UTC+1, Ian Barber wrote:

Firebase DevRel here, yep Andrew's response is a great place to look. The article is right that the developer saw a spike in costs, but it was a very specific set of circumstances (very high TLS to data ratio, and previous billing not including TLS bandwidth due to an undercounting bug our side) that is unlikely to apply to you. 

Even if the high TLS usage circumstances did apply, you'd see it right away now - the unfortunate thing in the post was that the developer started using the service during a period where we weren't charging correctly, so it appeared as a big spike when the issue was fixed.

As Andrew says, we're looking at options for improving the profiler to make these kind of things more easily visible. 

Mainly though, all of us here are really sorry the developer had a bad experience: a lot of that was due to the delay in communications from our side, and we're looking at ways of improving that. 

Hopefully that gives you an idea of what happened, but happy to clarify more: we want our pricing and billing to be predictable. 

Ian 

On Wed, May 17, 2017 at 10:33 AM, Piotr Kaminski <pi...@ideanest.com> wrote:

I'm guessing the Firebase team is busy at I/O today, but here's Andrew's public response to the post:  https://medium.com/@startupandrew/firebase-founder-here-im-very-sorry-for-the-surprise-and-frustration-experienced-by-the-poster-b0065c99f53e

    -- P.

On Wed, May 17, 2017 at 8:42 AM, zahid ali <syed.zahi...@gmail.com> wrote:

Hi,

I am creating a product which is using Firebase. Today i read this article (see link below) and it freaked me out. Me and my startup cannot afford such abrupt spike in price.

Can anyone explain what is the reality. Is this article saying truth.

https://medium.com/@contact_16315/firebase-costs-increased-by-7-000-81dc0a27271d

--
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/713fa4fe-4e33-4d1c-a3c0-41c7a6d5ae7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

  Piotr Kaminski <pi...@ideanest.com>

  "That bun is dirty.  Don't eat that bun."

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

[Kato Richardson]

Not sure exactly what you mean, James. Usage for what? We don't actually charge for Auth requests--it's an entirely free service.

Note that authentication attempts do have abuse protection. I can't talk a lot on the security measures, but obviously we look at the obvious things, such as number of requests from a given IP, and so on.

☼, Kato

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/96949fe8-1191-4042-9552-8daa6575de8c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Ian Barber]

I think the concern in this case is rules-rejected requests, so unauthenticated requests to a database path. Its a fair point: those will trigger TLS setup and tear down, and could be used as part of a denial of service attack or to run up billing maliciously. 

However, they could also be a case where a developer has deployed an application with a bug that is making many queries with the incorrect auth, and genuinely using bandwidth! We want to make sure we're billing fairly for resources used. 

In either case, we want to work with developers to make sure these things don't happen. As Kato says, abuse protection is a significant concern for us, and we want to support developers whether they get hit by an attack or have an error.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEZs19oQMWHC3_m35Ua8sgF2gxcN%3D-rVCayEfE472HmAXw%40mail.gmail.com.

[Peter LoBue]

Does using an official Firebase library also trigger TLS setup and tear down, or does that only apply to REST? Does it apply for every request, or is a connection "kept open" for a while (how long?)? Is there any more documentation on TLS bandwidth usage?

For reference, the author of the original Medium post talked to a Firebase engineer on the phone who said bandwidth for TLS setup was about 3KB. He shared this in the Firebase Slack group. 3KB! I shave down every byte I can with my Realtime Database structure and property names to save bandwidth (and storage of course), but with +3KB per request that feels a bit silly for my lower usage apps...

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/96949fe8-1191-4042-9552-8daa6575de8c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

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

[Ian Barber]

The TLS overhead is per-connection. The official libraries generally use websockets, so many requests are sent over the same connection. Even with the REST API, its generally more efficient to establish a connection and do a series of operations, and keep the connection open where possible. 

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/798702a3-0be8-4fed-b473-51d41efa8c1e%40googlegroups.com.

[Peter LoBue]

Thanks Ian for the further info. When you say "even with the REST API..." do you mean that we can control how many operations are performed over a single connection via REST? How would we do that?

[Tyler Rockwood]

You can do this via Keep-Alives for REST requests: https://en.wikipedia.org/wiki/HTTP_persistent_connection