I'd highly recommend people to stay away from Firebase. The querying options are really lacking. You'll likely get much better performance for much cheaper, and easier to develop for with a cheap postgres instance.
It's a case of using the right tool for the right job. It is indeed lacking for complex queries, and those use cases should probably stick with SQL.
I've been surprised over five years of using Firebase how often complex queries weren't necessary, though! I highly recommend using Firebase if you want realtime data synchronization and great client libraries as well as easy auth and some nice integrations with cloud functions and the like.
I don't mind using SQL (and I would actually prefer it) but what I want to avoid is having to build an api middleware with auth for my personal projects. Are there any alternatives to firebase you would recommend that would allow me to use SQL without having to build out an API?
I was in the exact same position as you one year ago. Then I found Hasura (https://hasura.io) and built Nhost (https://nhost.io). While building Nhost I always had Google Firebase in mind regarding how good they are for the developer experience.
I went through the exercise of replaceing our Firebase with Postgres last year. In the process I built a middleware abstraction that I am opensourcing now : https://supabase.io
Combined with graphql-codegen you can essentially generate react hooks from a Postgres schema. It’s awesome - and all typed if you’re using typescript too
May I ask why? I've always found this to be one of the simplest and least painful parts of any web project. And any 3rd party server has inevitably become a problem when the project grew to the point that we wanted something that they didn't have a solution for.
I went through this exercise myself. Tried to use Firestore and eventually ended up with a $7/mo postgres instance when I realized that my data storage and usage just did not fit well with it. Especially around sorting and pagination.
That said, bluntly telling people to stay away from Firebase as a whole, isn't really the solution here. There are many products available and they are all quite good. I think that everyone should look at their use cases and make their own call on the matter.
I'm still using the realtime store because I'm also using firebase auth (which is excellent). I can update a timestamp for the user in the realtime store and all my clients automatically get triggered. Firebase hosting and firebase functions are pretty nice as well, with very little vendor lockin.
FWIW it's worked well for us, but our application has the follow characteristics:
1) Our data is relatively small and well-scoped, so we're only querying small amounts of data (maybe 10-20 queries each of <50 records) from any individual client
2) We care a lot about real-time, so we want data manipulation on one client to show up pretty immediately on the other
3) While we'd definitely save money switching to a Postgres instance, we're not spending that much to begin with on Firebase.
I think these play well to Firebase's strength. In a previous life I built an app that sucks in a lot of data exhaust and then visualizes it... IMO Firebase wouldn't have worked well for that.
Are you referring to Firebase's Realtime Database (often just called "Firebase" since it was the core feature for so long) or Firebase's Cloud FireStore? FireStore is much better (scales more and has more query support) and covers pretty much the same use-case.
