back

by mayop100·13y ago·view on hn ↗
[Firebase founder] I would caution against comparing our pricing to S3 or any other non-realtime storage service. Firebase's use case is primarily for serving structured data (the type of data that lives in a database). For most apps, this is a small piece of overall data usage. Your site probably spends most of its bandwidth usage on downloading static content -- HTML, CSS, images, videos, etc -- which you don't need to store in Firebase (you can, but if you're looking for a cheap way to store big video Files, Firebase is not the answer).

Also keep in mind that for most apps, 90%+ of infrastructure costs come from running servers, not bandwidth. So while we may seem more expensive than other services, we eliminate your costs for servers and backups. The only thing you pay is the per-bandwidth/storage price. Also keep in mind that Firebase apps can often use less data per-user than traditional apps, since they push data only when it changes, rather than polling.

The vast majority of the apps on Firebase today will fit nicely in our free plan.

1 comments
I wasn't comparing Firebase to S3 (etc) so much as to what bandwidth actually costs service providers.

The only rational explanation I can come up with for the high cost is that it's a means of throttling use until you can acquire greater scale.

I've tracked Firebase with great interest since first hearing about it on HN. I'm disappointed by the cost, but I'm willing to give it a try and see how the value proposition ultimately stacks up.

In my use case, bandwidth is the primary cost concern with Firebase, but it's all text data (constantly dumped, so storage requirements are modest).

Keep in mind that most of our costs are also not bandwidth. Our primary costs are the servers, our CDN, backups, and operations. Bandwidth is just one small piece.