Live data from Hacker News

How we spent $30k in Firebase in less than 72 hours

hackernoon.com

1–10 of 249 posts

Re: How we spent $30k in Firebase in less than 72 hours

#3
This is why infinitely scaling pay-as-you-go cloud services terrify me.

I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met.

All it takes is a rogue line of code in an endless loop or something, and you are bankrupt.

Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for less than $100 a month on AWS?

Re: How we spent $30k in Firebase in less than 72 hours

#4

This is why infinitely scaling pay-as-you-go cloud services terrify me. I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met. All it takes is a rogue line of code in an endless loop or something, and you are bankrupt. Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for l…

Even with a cap, a rogue line or a legitimate surge in traffic could shut down your app.

It's endless bill monitoring and budget approval.

I'll stick to a flat rate DO droplet.

Re: How we spent $30k in Firebase in less than 72 hours

#6
I can't say enough good things about Firebase and GCP in general, but I'm always cautious when using Firestore in particular. I usually avoid unbounded queries altogether, and treat it primarily as a key/value store to get by id.

When I do use queries, it's always in places where the results have a well-defined limit (usually limit = 1), e.g. finding the most recent X or the highest X.

With the above two, you get all the greatness of Firestore, but with a well-defined (low) cost that you can calculate ahead of time.

Re: How we spent $30k in Firebase in less than 72 hours

#7

This is why infinitely scaling pay-as-you-go cloud services terrify me. I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met. All it takes is a rogue line of code in an endless loop or something, and you are bankrupt. Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for l…

From what I understand, AWS at least is pretty good about giving you at least one "get out of jail free" card if things go awry.

Caps are tough though. I can certainly understand a use case that would want a hard circuit breaker that just kills everything it can once it hits a certain threshold. Sort of; you presumably don't want everything on S3, for example, to be deleted.

On the other hand, moving up the scale of serious businesses, I can imagine it would be hard to specify circuit breakers (rather than just alerts) and you get into issues of terminating services that affect all sorts of other services across the entire account.

Re: How we spent $30k in Firebase in less than 72 hours

#8
post #4

This is why infinitely scaling pay-as-you-go cloud services terrify me. I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met. All it takes is a rogue line of code in an endless loop or something, and you are bankrupt. Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for l…

Even with a cap, a rogue line or a legitimate surge in traffic could shut down your app. It's endless bill monitoring and budget approval. I'll stick to a flat rate DO droplet.

Well, a rogue line could potentially as much shut down your app hosted in DO.

Re: How we spent $30k in Firebase in less than 72 hours

#10
post #7

This is why infinitely scaling pay-as-you-go cloud services terrify me. I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met. All it takes is a rogue line of code in an endless loop or something, and you are bankrupt. Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for l…

From what I understand, AWS at least is pretty good about giving you at least one "get out of jail free" card if things go awry. Caps are tough though. I can certainly understand a use case that would want a hard circuit breaker that just kills everything it can once it hits a certain threshold. Sort of; you presumably don't want everything on S3, for example, to be deleted. On the other hand, moving up the scale of…

There's nothing guaranteed about a "get out of jail free" card, so factoring that into your decision making is probably a bad road to go down.
Post reply on HN