Ask HN: Does any one know if Firebase is a successful from Google's perspective?
Recently, we haven’t seen much marketing for Firebase, Google’s core Backend-as-a-Service product.
Given Google’s well‑known reputation for discontinuing products that don’t meet its internal success criteria, I’m wondering whether Firebase is considered successful by Google’s standards.
They’ve already begun deprecating individual services under the Firebase umbrella—for example, Firebase Dynamic Links (https://firebase.google.com/support/dynamic-links-faq).
Does anyone know where Firebase’s App Backend‑as‑a‑Service is headed?
Firebase justifies its existence by serving as a customer acquisition vehicle for GCP. This is actually quite valuable given the huge marketing costs required to get a new enterprise cloud customer.
You're likely concerned about the precedent of Facebook shutting down Parse back in the day, leaving many projects stranded. Facebook though had no real commercial interest in cloud services back then.
They didn't shut down Parse though. You just had to self-host it. But somehow when Big Tech drops support for anything, people just migrate out of it for no reason and it becomes a self-fulfilling prophecy. Like Flutter careers are completely dead in the water now. One of my businesses has been running on Parse Server for half a decade and there's still updates on Parse. And despite being "dead", I still find Parse easier to code with than Firebase, though Supabase is now the favored option.
Fair point. But only a small minority of back end as a service users are comfortable with self hosting something like Parse.
Enterprises really like having someone to sue when things go wrong. And indie devs who pick BaaS offerings do so in large part to avoid the hassle of self hosting.
A bit off topic, but I wrote a guide to do this on Herok for anyone curious: https://smuzani.medium.com/setting-up-a-mobile-backend-serve...
I'm not sure if it's still valid but it's not too hard, and still much easier to maintain than dealing with AWS. I have basic AWS proficiency, but it's still good to have Heroku to not think about it.
Why are flutter careers dead?
It's a brilliant on-ramp for that, too, with high free usage caps that let you get projects up and running at no cost.
Firebase hosting only charges you when an actual thing you've deployed starts getting significant usage. It's a terrific option for small devs who still want custom domains, backend data, and the freedom to code in JS/TS in the browser.
Yeah but if you need features like Cloud Functions or SMS auth you have to give your credit card... with no spending limit... and the standard practice is to expose your firebase creds on the client... and their stated stance is its better to let you get attacked and then maybe waive the charges than to interrupt service to your site for a few hours... lol. Your recourse is to go viral on social media and get them to forgive the debt.
As a small dev firebase is horrifying.
It's annoying, but I'm not aware of anywhere you can get SMS auth without similar issues? Would love to learn if there are any.
Supabase does. It has a spending cap, so you won't wake up to a 100k bill if you get hacked. An app I recently consulted for used fireabase SMS auth. Someone spammed their sign-in page and they were hit with multiple 4-figure charges. Firebase refuses to refund of course. Its a great model until it really, really isn't.
For big companies like this, I like to go look at the activity on sdks and related projects. Typically activity will flat line before a sun setting announcement is made. Its hard to say how much lead time that buys you, but I have found it a useful barometer.
It seems like the firebase repos have had a fair amount of activity.
https://github.com/orgs/firebase/repositories
I don't see Google ending firebase anytime soon, but I don't like building inside of closed systems anymore.
It's very very difficult to migrate to a different service provider. Since Firebase is ultimately closed source, it's not your app. Your sharing it with Google.
Running a custom solution with Render(Heroku, etc) takes a bit more effort, but it's mine. I can actually open source it. I have more control.
For my current project I went from Firebase, to Superbase and settled on Django. I have some fairly complex logic and supabase just wasn't cutting it.
Literally yesterday a friend linked the announcement of Firebase Studio with AI building of apps on Instagram: https://www.instagram.com/reel/DIRCBFCyk4X/?igsh=OHlraW5jYWt...
Which is quite different
What's quite different?
The original Firebase and what Google is calling Firebase Studio
It is still used a lot by many hundreds of corporations and likely makes them profit, so I would assume yes.
We use it too, but anything that requires actual funds, we would migrate to AWS or refactor.
Like we'd use to allow PMs to change banners/copy on the fly, but Supabase is better. It does RAG but Supabase does that better too. Firebase functions are really good for prototyping, but once it starts to cost money, we move it to AWS. It's good for feature flagging, and we moved that to Growthbook. Analytics started on Firebase and were moved to open source so we'd own the data. The only thing they do well is Crashlytics and that's free.
If everyone was as bad a customer as us, I would assume they're in trouble.
Unfortunately a lot of people have trust issues with Google. We don't want them controlling data and certainly nothing as core as functions, DB, and feature flagging. Then when people don't use these things, Google kills it real fast.