[jackconsidine]

I love the concept of Supabase. The Firebase model is powerful but gated. For example, I recently had a project exceed FB's quota of functions- you can't deploy more than 60 endpoints in a minute which is a nightmare for CI pipelines which redeploy the entire app [0].

We recently tried Supabase on a "frontier" project, and found that it wasn't quite mature enough for production use in our case. Intermittent network errors and lack of an up-to-date status page hampered productivity a bit. These API changes seem like steps in the right direction.

[0] https://firebase.google.com/docs/functions/quotas

[ishanr]

I use supabase as our backend for https://sudopad.com and recently crossed 1000 shared links. Has been pretty stable for me. The only thing I am waiting for is the ability to call a subabase function on db change.

[kiwicopple]

supabase ceo here

> Intermittent network errors

I'm curious about where you're seeing these errors - is this your database functions or "Edge Functions" (Deno)?

[no_wizard]

I fundamentally disagree with this limit due to the fact they provide no alternative when you start getting into that area (I imagine scaling to 120 or 180 is going to be painful for instance). I'm really shocked they don't have a way for a customer to get this quota changed if on an enterprise account for instance (usually there is some byline to the effect of "if you need a higher quota please contact your account rep" sort of thing, but there is none of that here, which tells me no matter the size this is ironclad)

Off topic but I am curious:

Why re-deployed unchanged code?

The user-land solution I can think of is cached builds that only re-deploy changed code?

[jackconsidine]

Good question- Firebase doesn't have an API to only modify changed functions. We've structured our projects such that a changed file basically has a one-to-one correspondence with a changed function, and this you can derive from git-triggered CI/CD, but we've found that selectively launching changed functions is tantamount to stipulating every function from CI code which we've found to be brittle

[latchkey]

Why not have a single function that uses a router? Just map /* to the function and within the function, make your calls to other discrete handlers.

[jackconsidine]

That is the exact solution we went with :)

[latchkey]

So then why mention that FB is gated? It isn't gated, the design of your application was off.

[jackconsidine]

This is obviously a (hacky) work-around. Firebase Functions are designed to be deployed individually- abandoning that costs you GCP log traces and boilerplate right off the bat. Read the Firebase Functions documentation, and you'll see no mention of designing your application this way.

[latchkey]

I always assumed it wasn't documented as such because it is a bit more complicated to set up / describe and they were trying to keep the docs simple.

Once you get past a certain amount of endpoints, I'd always want to declare my endpoints in code rather than be tied to their config.

Never had an issue with the logs. Requests still show up.

[ibero]

it is gated. 60 endpoints in a minute. thanks to OP i now know this.

[latchkey]

Sure, maybe I'm reacting more to calling it a nightmare. This is a well documented limit.

First thing I always do is read the quotas/limits on any google cloud product before I use it.

Then, I'd notice the increase in deployment times on my CI server as more functions were being added and inspect what was taking so long and try to optimize it. Those individual endpoints take a while to deploy...