This seems like a pain point easily solved by a niche firebase-to-something-else migration tier. Seems like there's a small but possibly profitable company waiting to be created here:
- Gather firebase's "true" API surface/interface, create a model in your typed language of choice. This might be easier/harder depending on how many special features there are... I haven't really seen openapi schemas for firebase, but that would make this really easy.
- Make implementations that don't save to firebase (and probably one that does, since it'd be very easy to write and would be a good baseline)
- Create a per-version fork of the firebase SDKs (ex. JS[0]) that points at your servers instead of Google's
- Offer a cheaper firebase (you could aim at Heroku customers?)
- Offer a painless migration from firebase as a feature
- ????
- Profit
Business model risks: Google lowering prices on firebase, doing this themselves, etc.
Sorry if it wasn't clear -- this is an idea on how to capitalize on people picking Firebase and then wanting out later. I think there's a similar business here for getting people off of some other famous data stores (particularly in the document storage space) as well -- not limited to firebase.
Trying to convince everyone in the world to use the right solution for their actual problem the first time (and effectively going against Google's marketing machine, momentum of the general project, discounted plans, etc) is not my cup of tea.
IMO the right database for the overwhelming majority of startups is Postgres, vertically scaled until it needs read-replicas. The extension ecosystem, burgeoning support for configurable table access methods makes it a no-brainer. I don't have sufficient experience to back this statement (I haven't run that many startups, I don't run an accelerator/VC, etc) but I'd love it if some else that could refute it would show up.
I don't think this line of thinking is wrong, as often it is better to just start with Postgres. But Firebase does offer some nice advantages at the start of a project.
1. Generous, hosted free tier. I don't have to fiddle with setting up a database or paying for it. And I really do mean generous. You can run a small business off the free tier if you code it in a way that doesn't use unnecessary reads and writes. I've done it.
2. Development speed. It's all schema-less, which is (sometimes) one less thing to worry about at the start of a project. Firestore is the fastest way to get a functional proof-of-concept I have ever seen.
3. Realtime. This means your frontend gets instant live updates out of the box. This can be pretty hard to achieve with other solutions, but comes free with Firestore.
4. Securely connect directly from the client. This means you don't need a backend at all, which is a huge win when you're just tinkering.
5. Amazing cross platform support. Setting up the connection to the database from iOS, Android, or Web takes a matter of minutes.
Now, a lot of these early wins come with growing pains later on. But early wins are still a great thing if it is the difference between your project getting off the ground, or failing from the start. I don't really use Firestore anymore, but there is a lot I liked about it.
- Gather firebase's "true" API surface/interface, create a model in your typed language of choice. This might be easier/harder depending on how many special features there are... I haven't really seen openapi schemas for firebase, but that would make this really easy.
- Make implementations that don't save to firebase (and probably one that does, since it'd be very easy to write and would be a good baseline)
- Create a per-version fork of the firebase SDKs (ex. JS[0]) that points at your servers instead of Google's
- Offer a cheaper firebase (you could aim at Heroku customers?)
- Offer a painless migration from firebase as a feature
- ????
- Profit
Business model risks: Google lowering prices on firebase, doing this themselves, etc.
[0]: https://github.com/firebase/firebase-js-sdk