Somewhat off topic question though: if you guys are such skilled developers to be building something as involved as this, why not just use something other than Firebase? I used Firebase mainly as a crutch when I was first getting into web dev, but feel that I’ve sorta outgrown it. Do you feel Firebase still serves developers like you well or are you developing this moreso for people like my old self?
Thanks Josh! Of course I'm using many other services other than Firebase. But Firebase even on 2026, I feel it still does what is suppose to do well. It does have many gaps tho, but tons of small projects or for beginners where it's really easy to get started with Firebase.
And surprisingly, there are still many large scale mobile app and webapps that's running on Firebase. For most of them, the local development without costing them, depends on this local emulators suite.
Compare to the alternatives like Supabase, where the team are really focused on giving best dev exps, for some reason Firebase local development has been the same for a long time.
I personally thought, giving that best dev exps locally for Firebase, could give devs a fresh of breath air for maintaining or developing new projects faster.
Firestore's subcollection feature is pretty cool. As far as NoSQL dbs go, it's flexible query and indexing make it more suitable to app development than, say, DynamoDB.
To me, the lack of good developer tooling has been what holds it back. Not having a maintained type-safe querying ORM/ODM library like eg. Prisma or Mongoose is a major flaw imo (not to mention missing out on the coolest firestorm)
Sharing my perspective as a big time user of Firebase:
1. It is practically free for a lot of my projects. Yes, there are also other free platforms out there now, but because Firebase is largely an abstraction on GCP, I have more reach if I need to scale it or move it into a more capable backend that I have full control over (very natural progression from Firebase -> Cloud Run -> GKE Autopilot -> GKE). For a few use cases, I do pay (e.g. keep a warm Function for an auth flow).
2. Firebase auth is still really, really good. It is super easy to get SSO working with Firebase auth. End of the day, it is largely (entirely?) just an abstraction on top of Google OAuth API, but it is by far the easiest and most foolproof of the solutions on Azure, AWS. And again, for most use cases, it is entirely free.
3. A well-designed Firestore backend is for all intents and purposes free for side projects and can still scale without the need to overthink it. I have had a few projects that had big Reddit spikes and Firestore just swallows the volume like a champ (that would have swamped a small Pg instance). I have run several side projects, blogs, etc. for years purely on Firebase because Firestore's free tier is really, really generous and when you pass those limits, the pricing is still reasonable. Ridiculously generous.
4. Firestore gives you real-time websockets with no additional infra needed and again, practically free for most side projects. Cloudflare now has PartyKit which fills the same niche, but Firestore's real-time subscriptions are nice because of how integrated they are into the backing store. Amplify's AppSync (when I used it last) was janky AF; did not like it at all and did not like the fake relational abstraction over DynamoDB (dangerous at scale). Azure SignalR, Web PubSub, and Fluid Relay are not free or they are not usable at the free tier beyond initial sandboxing.
5. It is easy to operate. If you want to run directly on a hyperscaler cloud (AWS, Google, Azure), Firebase is the best tooling. Azure doesn't really have an equivalent. AWS killed off their Copilot CLI[0] which I felt like was approaching the utility of Firebase and not a fan of Amplify (which seems to have changed direction recently). I was a fanboy of CosmosDB, but Microsoft refused to ship a working ARM64 emulator version for YEARS[1] which made it unusable on Mac. I am comfortable operating at any layer of any of AWS, Azure, GCP, but most of the time I only want to when I need to. So Firebase lets me ship something fast, but drop down into the underlying cloud infra when I need to.
6. Until recently, the other platforms did not have great options for emulation. I think AI has changed that and now we are seeing more proliferation of platform emulators. LocalStack, for example, had already locked some of their emulation behind paid licenses. Firebase emulators were pretty complete in terms of what was needed to build and ship an app end to end. The OAuth emulator is still really, really nice.
Why didnt you simply provision more powerful developer boxes to handle the needs of the Firebase emulator?
If runtime performance is the moat then won’t Google simply improve on these regressions using their decades of cloud database expertise with projects like Google Spanner?
—-
These are hardball questions and I feel a bit bad asking them, but I believe asking hard questions is kinder than blind adulation and support.
> then won't Google simply improve on these regressions using their decades of cloud database expertise
The developer experience of trying to emualate firebase locally has always been horrible, going on fifteen years, so I would guess no, they won't because they don't care.
Would disagree here given that Firebase is the only one of the three owned platform toolkits (Azure, AWS, GCP) that has a really complete first party emulator suite.
That feels like it's more a function of the lack of a query UI whereas Pg and Mongo have a lot of options.
I used Firefoo for a while and Google should just buy that product and ship it with Firebase. Otherwise, I have no issues with local Firestore emulation; everything works as I expected it with a few edge cases.
Have you ever come across Fuego or had a chance to try it? It supports complex Firestore queries, including Firestore Enterprise pipeline queries and Point-in-Time Recovery (PITR).
Hi there, don't feel bad asking these questions. In fact, i had this questions in mind too while this project was started.
Firstly, we already running of powerful dev boxes but still hitting out of memory issues in the official local emulators. These stronger machines doesn't remove Java or replaces the old console UI or able to loads tons of data.
Google should fix it and it's expected, but for some reason, they haven't really prioritized local tools for local devs. In other ways of saying, some one had to take this in hand and try it out, and well we did :)
Appreciate the reply, further I'd add that: Even if both my proffered solutions came to pass and 1) many paid the compute prices for bigger dev boxes and 2) Google did overhaul the emulator, then your solution could still be a viable business if it provided sufficient value for Firebase users in being more responsive and tailored to their needs - especially given big companies like Google are notorious for abandoning even wealthy client demographics.
This is really neat! I've been working on an open-source version of the Firebase Realtime Database as well that might be of interest[1]. Also written in Rust! Might be a good basis for building out the Realtime Database part of Firenook if you have any interest in supporting that as well.
Thanks and Lark looks really good and interesting!! Will definitely look into it as I do have plans to integrate Realtime Database into Firenook too :)
Awesome, not surprised to hear that Google still neglects to improve this experience, but you called out exactly why:
> [...] the only way Firebase developers can build apps without directly costing them is using the official Firebase Emulator Suite
We had started on the management UI portion of this at my old job out of similar frustrations. Felt awful seeing what should be a small/medium sized development-only application spew forth Java flotsam.
If you can get application integrations running on an emulator I would seriously consider switching my team over. I know that's technically outside of Firebase, but we use a Frankenstein's monster of GCP and Firebase for our services.
Technically it's possible. But right now we are focused on getting the emulator right, so that once we do self-hosting, it would be really reliable and we can run production data securely.
Well, right now plans are there to make Firenook to run locally perfect first. I was thinking, once it's well stable, to make it self-hosted first before thinking of any cloud versions. But I'm curious to ask, may I ask which service you're going to use it for in cloud?
(Firebase founder) This is very cool! Great work!
Thanks a lot James, couldn't be more happy that you're liking it :)
Looks nice!
Somewhat off topic question though: if you guys are such skilled developers to be building something as involved as this, why not just use something other than Firebase? I used Firebase mainly as a crutch when I was first getting into web dev, but feel that I’ve sorta outgrown it. Do you feel Firebase still serves developers like you well or are you developing this moreso for people like my old self?
Again, nice work!
Thanks Josh! Of course I'm using many other services other than Firebase. But Firebase even on 2026, I feel it still does what is suppose to do well. It does have many gaps tho, but tons of small projects or for beginners where it's really easy to get started with Firebase.
And surprisingly, there are still many large scale mobile app and webapps that's running on Firebase. For most of them, the local development without costing them, depends on this local emulators suite.
Compare to the alternatives like Supabase, where the team are really focused on giving best dev exps, for some reason Firebase local development has been the same for a long time.
I personally thought, giving that best dev exps locally for Firebase, could give devs a fresh of breath air for maintaining or developing new projects faster.
Firestore's subcollection feature is pretty cool. As far as NoSQL dbs go, it's flexible query and indexing make it more suitable to app development than, say, DynamoDB.
To me, the lack of good developer tooling has been what holds it back. Not having a maintained type-safe querying ORM/ODM library like eg. Prisma or Mongoose is a major flaw imo (not to mention missing out on the coolest firestorm)
+1 to the NoSQL point. I also like that you get the consistency guarantees and joins / aggregates you’d expect from relational databases.
Firestore now provides MongoDB compatibility and Mongoose suport, so you can use it this way: https://docs.cloud.google.com/firestore/mongodb-compatibilit...
Sharing my perspective as a big time user of Firebase:
1. It is practically free for a lot of my projects. Yes, there are also other free platforms out there now, but because Firebase is largely an abstraction on GCP, I have more reach if I need to scale it or move it into a more capable backend that I have full control over (very natural progression from Firebase -> Cloud Run -> GKE Autopilot -> GKE). For a few use cases, I do pay (e.g. keep a warm Function for an auth flow).
2. Firebase auth is still really, really good. It is super easy to get SSO working with Firebase auth. End of the day, it is largely (entirely?) just an abstraction on top of Google OAuth API, but it is by far the easiest and most foolproof of the solutions on Azure, AWS. And again, for most use cases, it is entirely free.
3. A well-designed Firestore backend is for all intents and purposes free for side projects and can still scale without the need to overthink it. I have had a few projects that had big Reddit spikes and Firestore just swallows the volume like a champ (that would have swamped a small Pg instance). I have run several side projects, blogs, etc. for years purely on Firebase because Firestore's free tier is really, really generous and when you pass those limits, the pricing is still reasonable. Ridiculously generous.
4. Firestore gives you real-time websockets with no additional infra needed and again, practically free for most side projects. Cloudflare now has PartyKit which fills the same niche, but Firestore's real-time subscriptions are nice because of how integrated they are into the backing store. Amplify's AppSync (when I used it last) was janky AF; did not like it at all and did not like the fake relational abstraction over DynamoDB (dangerous at scale). Azure SignalR, Web PubSub, and Fluid Relay are not free or they are not usable at the free tier beyond initial sandboxing.
5. It is easy to operate. If you want to run directly on a hyperscaler cloud (AWS, Google, Azure), Firebase is the best tooling. Azure doesn't really have an equivalent. AWS killed off their Copilot CLI[0] which I felt like was approaching the utility of Firebase and not a fan of Amplify (which seems to have changed direction recently). I was a fanboy of CosmosDB, but Microsoft refused to ship a working ARM64 emulator version for YEARS[1] which made it unusable on Mac. I am comfortable operating at any layer of any of AWS, Azure, GCP, but most of the time I only want to when I need to. So Firebase lets me ship something fast, but drop down into the underlying cloud infra when I need to.
6. Until recently, the other platforms did not have great options for emulation. I think AI has changed that and now we are seeing more proliferation of platform emulators. LocalStack, for example, had already locked some of their emulation behind paid licenses. Firebase emulators were pretty complete in terms of what was needed to build and ship an app end to end. The OAuth emulator is still really, really nice.
[0] https://aws.github.io/copilot-cli/ : literally their best infrastructure tooling and they killed it....................
[1] https://github.com/Azure/azure-cosmos-db-emulator-docker/iss...
This post also begs the question:
Why didnt you simply provision more powerful developer boxes to handle the needs of the Firebase emulator?
If runtime performance is the moat then won’t Google simply improve on these regressions using their decades of cloud database expertise with projects like Google Spanner?
—-
These are hardball questions and I feel a bit bad asking them, but I believe asking hard questions is kinder than blind adulation and support.
> then won't Google simply improve on these regressions using their decades of cloud database expertise
The developer experience of trying to emualate firebase locally has always been horrible, going on fifteen years, so I would guess no, they won't because they don't care.
Would disagree here given that Firebase is the only one of the three owned platform toolkits (Azure, AWS, GCP) that has a really complete first party emulator suite.
I would agree that Firebase is better now than most vendor-locked dbs which often don't have an emulator at all.
But local developer experience is still not good compared to Postgres or Mongo.
That feels like it's more a function of the lack of a query UI whereas Pg and Mongo have a lot of options.
I used Firefoo for a while and Google should just buy that product and ship it with Firebase. Otherwise, I have no issues with local Firestore emulation; everything works as I expected it with a few edge cases.
Have you ever come across Fuego or had a chance to try it? It supports complex Firestore queries, including Firestore Enterprise pipeline queries and Point-in-Time Recovery (PITR).
Hi there, don't feel bad asking these questions. In fact, i had this questions in mind too while this project was started.
Firstly, we already running of powerful dev boxes but still hitting out of memory issues in the official local emulators. These stronger machines doesn't remove Java or replaces the old console UI or able to loads tons of data.
Google should fix it and it's expected, but for some reason, they haven't really prioritized local tools for local devs. In other ways of saying, some one had to take this in hand and try it out, and well we did :)
Appreciate the reply, further I'd add that: Even if both my proffered solutions came to pass and 1) many paid the compute prices for bigger dev boxes and 2) Google did overhaul the emulator, then your solution could still be a viable business if it provided sufficient value for Firebase users in being more responsive and tailored to their needs - especially given big companies like Google are notorious for abandoning even wealthy client demographics.
This is really neat! I've been working on an open-source version of the Firebase Realtime Database as well that might be of interest[1]. Also written in Rust! Might be a good basis for building out the Realtime Database part of Firenook if you have any interest in supporting that as well.
[1] https://github.com/lark-sh/lark
Thanks and Lark looks really good and interesting!! Will definitely look into it as I do have plans to integrate Realtime Database into Firenook too :)
Awesome, not surprised to hear that Google still neglects to improve this experience, but you called out exactly why:
> [...] the only way Firebase developers can build apps without directly costing them is using the official Firebase Emulator Suite
We had started on the management UI portion of this at my old job out of similar frustrations. Felt awful seeing what should be a small/medium sized development-only application spew forth Java flotsam.
Thanks, please give Firenook console ui a try and let me know if there's any missing ui portion that could make dev exp better.
If you can get application integrations running on an emulator I would seriously consider switching my team over. I know that's technically outside of Firebase, but we use a Frankenstein's monster of GCP and Firebase for our services.
At first I thought this had something to do with books because "Amazon Fire" plus "B&N Nook" = "firenook".
Can this be hosted on a node and I get firebase of my own?
Technically it's possible. But right now we are focused on getting the emulator right, so that once we do self-hosting, it would be really reliable and we can run production data securely.
this is awesome, great work. any plans to target replacing the cloud production services?
Well, right now plans are there to make Firenook to run locally perfect first. I was thinking, once it's well stable, to make it self-hosted first before thinking of any cloud versions. But I'm curious to ask, may I ask which service you're going to use it for in cloud?
well, actually this inspired me to try firebase for my next app instead of supabase (sorry supa, you are awesome)
Nice work.
This is very cool!
Nice!
Thanks :)