Firebase Costs Increased by 7,000%!

My Firebase experience had some parallels. Two months ago, I noticed by chance that I had exceeded my Firebase DB data download limit.

Given the current number of users, no reasonable calculation justified such excessive downloads. Similar to your case, Firebase’s tools were insufficient in diagnosing the problem. I began to worry that I’d have to bear the increased costs and scramble to reimplement on AWS, even though I knew nothing about it made sense.

I considered that my implementation involved a remote server writing to the DB every few seconds, but the charge was for downloads, not uploads.

After a friendly but ultimately unhelpful email exchange with Firebase support, I discovered the problem was indeed in the frequent writes. My remote server was writing to Firebase using the PUT method (REST API). By default, a PUT request to Firebase DB returns written data. So every few seconds, the data I wrote was also being downloaded in the same request! Adding “print=silent” in the request fixed the problem.

This was entirely my bad since the documentation clearly states the default behaviour. It was nonetheless a bold awakening and I couldn’t agree more with your point: Don’t naively accept the lure of easy-to-implement, wholistic services. In the hype of a new project, be disciplined enough to plan for future scenarios and the possibility of service switching.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.