You need to be a billionaire, and then you need to threaten to sue anyone who dares to ask you to pay.

https://firebase.google.com/docs/projects/billing/firebase-p...

I am not sure how they can do that, but cannot let people set their own limits on their paid plans.

That's fine. The major LLM providers work like this. If you're out of credit, or hit your monthly recharge limit, it stops working, bringing down prod with it if your product relies on it. Not heard anyone complain about the concept.

If it's really a problem for you, you can be all enterprisey and contact sales, then they'll be very excited to offer you extremely high limits and post billing.

This way everyone gets what they wants.

So you deploy an advanced technology known as a radio button to toggle which they want, throw a bunch of ToS & consent agreements about data loss / deletion at the ones opting for hardcaps....and done.

Also reminder that Azure has hard caps for certain account types. This is not a technical problem. They can do this, they just don't want to.

When you've exhausted your billing cap, what else could it do? Either shutting off services or blowing past the cap seem like the only serious options.

For a lot of small businesses, I suspect that an outage is often better than risking a surprise 6 figure bill. But it depends on what your software does.

Also if the system shut down automatically when the budget got exhausted, there's a risk that a runaway backup process or something might accidentally eat through your regular budget and get the site shut down. For that, it might make sense to assign different resources into different budgetary buckets or something.

I'm surprised firebase doesn't implement something like that.

They don't have a problem implementing caps on a free tier. No one's asking for perfect, but they don't seem to care about even getting to the ballpark.

I pay for storage. Does this mean they delete my production database? They delete my s3 buckets? They delete my server logs? My message queue?

Then yes! I would be extremely upset. How do you expect the cloud provider to magically know what is safe to "pull the plug" and what is not safe?

I have not been thrilled with Upwork, but that’s another story.

In general, I have found that you get what you pay for.

Why would I agree to pay up to $20k on a $50k cloud bill, when you could just choose to spend more on your cloud bill. I would be giving away free money and you'd get a discount.

You have to tie it to either incorrect billing, valid billing but caused by a malicious third party (i.e. hacking), or valid billing caused by negligence, and in the latter case you would need to prove negligence otherwise it's just a business deciding to use more resources and not pay for them. In the same way, fire insurance covers your house burning down, but not if you burn it down yourself.

If you wanted to sell such insurance, I'd be very happy to buy it for my upcoming $20,000 cloud bill!

This is where I question the risk of serverless. Although, now that I think about it, while my one client’s EC2 instances are essentially capped in terms of capacity and spend, we also use S3 etc. I suppose it would be entirely possible to accidentally write a huge amount of data to S3. But again I would rather get warnings from the app that writing to S3 has failed due to limits than get a huge bill!

This is not too hard if the billable event is, say, creating a VM. Creating the VM takes a few seconds, it's easy to add a quick API call to check billing. But what about the next hour, when you charge for the VM again? You now have the number of VMs checking in every hour (worst case, at the same time), and you need to handle all those hourly checkins consistently per customer.

That's still probably easy enough, but what if it's not a VM hour, but an API gateway request? Now on every single request you have to check in with the billing service. API gateways need to be very low latency, but you've just added a request to that process that possibly needs to go across the world to check in with the billing service running on another continent.

What if the billable resource is "database query seconds", and now you need to know how many seconds a query is going to take before you start it? Oh, and add the check in time to every database query. What if the billable resource is streaming video, do you check in on every packet you send out? What if it's CDN downloads, do you have every one of thousands of points of presence around the world all check in, even though the point of the product is to be faster than having a single far away delivery node?

There are bad workarounds for each of these, but they all mean either the cloud provider losing money (which, assuming a certain scale of customer, is too expensive), the customer over-spending (which assuming a certain scale, could still be waaay over their budget), or slowing down most services to the point that they functionally don't work anymore.

We have a multi-organization OpenAI account and I had set a $4k/month limit on one of the child orgs that was being used for a R&D project. Got billed ~$20k for the project one month and complained that it clearly allowed us to exceed our soft and hard limits. We were told that the limits (which you can set and act like they are a real thing) don't do anything if you have a child organization set up. They refunded us after some persuading and I know it's just normal growing pains for an organization that is undergoing rapid growth and maturity, but was still a little surprising that even the "hard limit" didn't do anything for us!

(Note that this was last year, so this bug is probably long fixed as they have redesigned their portal multiple times now)

For Firebase, their costs are probably pretty marginal.

https://www.microsoft.com/en-us/startups/blog/trusted-partne...

Also, assume I already have an LLC then how do I indicate this account is an LLC? Can you sign up as an organization on Firebase?

So it entirely depends on what it is you are doing.