2. Database? Firebase Cloud Firestore. Sometimes, you don't need SQL.
3. Push notification? Firebase Cloud Messaging
4. File storage? Firebase Cloud Storage
All of my needs are served by single platform. Seems like Supabase handles all of them, except #3. Let's try :)
For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function. While it can get confusing sometimes, I think Firebase has done a good job "overlaying" their functionality set on top of GCP infrastructure, e.g. "Cloud Functions for Firebase" is really just a very thin layer on top of GCP Cloud Functions, Firebase Auth is basically the same thing as Google Identity Platform, etc. The author of the blog post sees that as a negative in some areas, but I don't.
FWIW, I looked through the authors list of Firebase "cons", and as someone who has used Firebase for years, none of those have really been a concern for me. My biggest concern is that there are areas of Firebase that have been calling out for love for years, particularly Firebase Auth, but they've gotten virtually no updates. Apparently nobody at Google sees making these straightforward but important improvements as a path toward getting a promotion.
God no. The last time I checked, Firebase functions had intensively bad latency times for me. So bad that I decided to learn AWS Lambdas to get my work done. And yes, Lambda just blew Firebase and GCP functions out of the water.
The biggest innovations lately has been our release of v2. V2 is built on Run and can support concurrent executions in the same container. This dramatically reduces the number of cold starts, and makes min instances reservations even cheaper if you want to eliminate cold starts for a given workload. Plus, Firebase lets you configure CPU separately from memory in V2, so you can give functions extra oomph if they need it. Docs are at [1]
Finally, Firestore’s SDK was slower than we liked in GCF so we’ve done a number of improvements there. About half a year ago we redesigned the SDK so we could lazy load the networking layer. This lets you handle Firestore events without loading the bulk of the SDK. We have a more extreme update in the works that will let you configure the Firestore SDK to prefer REST over gRPC so you can avoid heavy dependencies in latency sensitive/event driven environments like GCF.
1. If cold start times are a big deal, you can now set a minimum number of instances with Cloud Functions so they don't scale to 0. You can also now set concurrency on Cloud Functions so one function can run multiple requests simultaneously on a single function.
2. There are tons of other serverless options if you want to, say, have a Firebase front end but a backend API served in your language of choice that uses the Firebase Admin API to do whatever you want, e.g. App Engine or Cloud Run.
You can set that, but the setting gets ignored and latency is still abysmal. That was literally the reason we moved our backend to Cloud Run.
Was this cold start latency specifically or request latency in general? Do you know what region you were deployed in?
There's also `subscribe` (https://supabase.com/docs/reference/javascript/subscribe)
They tend to word emails strongly to affect action.
As for the cost overruns: I don't know anyone who wrote one of those blog posts (or emailed support) who didn't get their bill refunded.
We can argue about spending caps or hard limits (which people generally dislike for their production apps), but the people side of the business is (or at least was) solid.
Source: worded emails strongly to affect action at Firebase and refunded a number of bills.
Firebase does have some issues but the core premise is solid and IMHO everything will be like that as we go forward.
I might be speaking as a jack of all trade so it seems easier to me. For a frontend only dev who needs a backend it might be different.
I agree in general: I choose netlify/vercel over S3+lambda or vps.
This is the main selling point of Supabase. Indeed, sometimes you don't need SQL. But in most cases you need SQL. Or you make awkward Firestore workarounds that are prone to introduce bugs and will definitely introduce complexity.