There are a couple of things I’d like to clarify for the group, to help folks understand what happened here, and hopefully help others avoid the same problem.
1 - The Firebase Realtime Database charges for SSL overhead on all requests (we charge for all OSI Layer 5 network usage). We’ve always had a policy of charging this way. Unfortunately, we introduced a bug late last year that began undercharging for SSL, so when the bug was fixed it surprised many people who had gotten used to the lower numbers. For most people, the change was very small. For a small number of people though with exceptional use cases (ie. tons of small network requests from IoT devices without support for session tickets), this can result in a larger change. We identified and contacted developers who were significantly affected, but this customer didn’t get the email. We should have done better. (we mention this change in our FAQ -- https://firebase.google.com/support/faq/ -- under “Why was my Realtime Database reported bandwidth lower than average”)
2 - We recently started actually enforcing overages on legacy plans and our current fixed-price ($25/mo Flame) plan. This is new -- in the past, we allowed unlimited usage on every plan, since we hadn’t built the tools to control this. This meant that many of our developers were getting far more than the listed limits for free. So you may start receiving emails now warning you of bandwidth overages, not because your usage patterns changed, but because we’re now enforcing limits for your existing usage. If you upgrade to the Blaze plan, you’ll start being billed for your full usage amounts -- so double-check your database’s “Usage” tab before upgrading.
I’ll be looking into our profiling tool to see if we can improve it to give a more complete picture of costs.
Again -- I want to apologize to the poster for the poor support experience. If others on the thread have had similar problems and feel they are not getting the attention they want from support, feel free to email me directly as well: email@example.com
As of wrongly billed resources - to be honest, you are half blamed for that. I often create apps and base on SAAS reporting to see if the script behaves as expected and uses as many resources as needed. You have misled developers to believe everything is alright and now you are punishing them. I would expect some credits for time being and "transition" period.
We do often give credits to help in situations like this, though I can't speak to specifics publicly. We're working with this developer to try to resolve the issue, and we'll do so with other users who run into similar problems. This user did contact support, but we dropped the ball here. We'll be reviewing our support to find other devs we might have missed.
I also wonder who shifts through the tickets themselves. Is it the engineer straight out of Stanford with 150k combined compensation and no serious training in customer satisfaction? The curious developer who built the product and wanted to see what people thought of his/her baby? A lower paid employee in a country with a lower cost of living? Some combination of the three? I feel like the culture at Google might preclude it from ever having good customer support except for the highest paying customers.
Googles real products are made out of meat 
> The Firebase Realtime Database charges for SSL overhead on all requests ... We’ve always had a policy of charging this way.
So it's always been charged.
> Unfortunately, we introduced a bug late last year that began undercharging for SSL
Except it hasn't always been charged?
> We recently started actually enforcing overages on legacy plans and our current fixed-price ($25/mo Flame) plan.
In fact, if you're on a Spark or Flame plan, it's never been charged?
I feel like this response is straight from Office Space or something. "So we just went ahead and fixed the glitch."
I'm guessing that OP's SSL overhead spiked after the measurement bug was introduced. Maybe also Firebase wasn't enforcing their limits before introducing the measurement bug, because they weren't confident about the data.
A feature might be rolled out "as is" to the entire user base after it was determined, on a small sample, that the costs per user were acceptable ; if the costs were greatly under-estimated, the company is left with a choice of discontinuing the feature (angering users) or scrambling to optimize the software, possibly starting from scratch with another technology. Or a yearly budget might have been designed based on usage estimates, only to be revealed as insufficient once actual estimates become available, and requiring an emergency cash injection for the company to pay for it.
I'm not a user of Firebase, but if our cloud provider (Microsoft Azure) were to announce that our costs had been underestimated by 2x or more, we would sue and argue that a 50% cost reduction for the past few years does not even begin to cover the strategic impact of the incorrect metric.
I have a question though...Why does Firebase charge ONE DOLLAR per gigabyte? 1995 called and wants their business model back.
This alone has limited my use of Firebase to Dynamic Linking for my app. Not that my app is going to smash any records, but paying customers are a good thing to get, aren't they?
That said I would be curious why storage is so expensive compared to DynamoDB ($5/gb/mo storage vs. $0.25/gb/mo).
Say, the $0.12/GB that Google Cloud Functions uses, since there's no value to the user or cost to the provider beyond what you'd see there (and indeed, one solution seems to be to simply route through cloud functions).
Is that possible, mayop100, or am I misunderstanding the system? Obviously it's not up to your users to dictate your pricing, of course, but if it's feasible it would probably earn a lot of goodwill.
That gets to the heart of the issue -- I think most people believe that if there had been an effective channel for communicating then the issue would never have been such a problem. But "we'll be working directly with this developer" only solves ONE PERSON'S problem. The message I would like to see you taking from this is that your team needs a better way for ALL users to reach out for support in those situations where the support is necessary.
I'm starting to really fucking hate Google.
Just go to https://support.google.com/googleplay/?hl=en and click "Contact Us" in the top right. All the menu items I clicked that don't have straightforward solutions went straight to a menu where within 2-3 minutes I can get live chat or a phone call.
I've also had no problems getting help with my paid Google Apps account when I need it. For cloud there's paid support with a 4-hour response time: https://cloud.google.com/support/
It's consistently very good - they helped us with code debugging, performance optimization, load balancing and other fairly complex issues that typically need an experienced engineer.
At the end he asked me to provide positive feedback to him in exchange for friendly service. He said he will redirect me somewhere and I should give him a proper feedback. This is even while I was telling me I have no time and this is an urgent matter. At the end of the call it turned out it took him 5 minutes to solve the issue and he just wanted to chat while I was stuck at talking to him, thinking he is waiting for a solution to propagate.
I can't say this is a good support.