I loved using Firebase & Firestore to build MVPs, but I would advise anyone tempted to use it, to avoid it. Every time I've embraced it, I ended up having to rewrite apps shortly thereafter. Your app becomes unavoidably coupled to it.
For those looking for a suitable alternative, we are building https://supabase.io
We're open source, just came through the last YC batch. We use Postgres for the database, with an airtable-like editor in the dashboard. Since it's Postgres, migration is easy too - just dump your database and take it elsewhere
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.
- Lack of schema makes it really easy write bad data without realising it. I inherited a 3 year old firebase/firestore codebase and database was FULL of inconsistent data. This was not helped by our application being in JavaScript meaning bad data could roundtrip all the way through our without triggering any errors. Only later causing obscure and hard to debug issues.
- Lack of query flexibility or joins make some use cases either impossible or very inefficient
- Connecting directly from client apps makes it very difficult to make backwards compatible changes. You can fix this by making everything go through backend APIs, but then you lose realtime which is the main benefit of firestore in the first place.
We're halfway through a port to Postgres+Hasura, and our app is much more reliable and responsive now.
I have seen people putting bad security rules often before. It makes me worried about using firebase apps.
No proper rate limiting, protected fields, dashboard sucks, opened feature requests for years without any answers, missing ton of small stuff I can't remember that is very easy to do on postgres (counters?), etc.
I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.
Those security rules tools look excellent. I had no idea that security rules could restrict the data shape. Our app only has basic read permissions configured (and we're not bothering updating them because we're moving all the data our of firebase anyway).
> I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.
Supabase looks really nice. I'd definitely consider it for new projects. The nice thing about Hasura is you have full access to the underlying Postgres DB. We are actually writing SQL for most of our data fetching needs with a traditional express backend. We're only going through Hasura when we need realtime capabilities. But it's pretty nice to be a bolt it on and get subscriptions out of the box :)
It's the same for supabase without the additional graphql layer. It runs a separate elixir project to convert postgres changes into real time subscriptions. You can use this without using other parts.
An architecture I've seen work is to have reads be direct from the client, but writes be through cloud functions. You can then do migrations and denormalization in the functions and the client sees the sync events as the write completes.
I do wish they'd add actual migration support though. Firebase has always needed some kind of document views like feature to allow backwards compat, but still allow changing the schema.
I don't understand why people are so keen on these "serverless" architectures. Why not just run a backend web server. It's generally the least troublesome part of the system, and it buys you a bootload of flexibility.
I'm currently using cloud datastore.. But tempting to use firestore cause its easier in the app... However my raw data schemas are often not exactly what i want to expose to the app.. I know it solvable with firestore, but only with firestore's solution..
Also the pricing setup, im just not sure about it.
Currently i have decoupled all database layer operations behind a Repository service in Golang.
Vendor lock-in is indeed a concern, but IMO the biggest concern is that Firebase only really works for MVPs. It's super easy to go from 0 to 10, but painful or even impossible to go from 10 to 100.
