HN Explorer

Ask HN: The state of Firebase alternatives in 2020?

69 points by kgraves ↗ HN
Looking for a Firebase alternative that is ideally production ready and open source.

Has there been any strides in this area and what is the current state of them in 2020?

Thanks.

40 comments

[ 2.6 ms ] story [ 113 ms ] thread
Wintereise
Good 'ol AWS lambda might be an option (+other PaaS services as needed).
dmd
That's kind of like saying a good alternative to air travel is "here's a pile of aluminum (and some machine tools as needed)".
[deleted]
(comment deleted)
habeyer
hasura.io
girishso
Yes Hasura looks like a serious contender. Uses Postgres as database and GraphQL interface. Supports real-time updates.
wh-uws
building a side project with hasura right now. has been pretty solid to work with
[deleted]
(comment deleted)
[deleted]
(comment deleted)
[deleted]
(comment deleted)
[deleted]
(comment deleted)
[dead] wh-uws
one more test
digianarchist
Is open source Parse still going?

https://parseplatform.org/

xgenecloud
XgeneCloud:

An open source alternative of Parse for SQL databases : https://github.com/xgenecloud/xgenecloud

* Instantly generates REST APIs & GraphQL APIs on 'ANY' MySQL, PostgreSQL, Microsoft SQL Server, SQLite & MariaDB databases.

* Has a built in GUI to design SQL schema which auto-generates reversible schema migrations.

* And lastly, the entire backend generated can be even deployed as a Lambda Function or GCP Cloud Function or Azure Function App!

Demos are below : Happy to answer any questions

[1] : GUI based schema designer : https://www.youtube.com/watch?v=ETEEcY4mmEg&list=PLhQvP2JTFb...

[2] : REST API creation : https://www.youtube.com/watch?v=gEU-QvmwSKQ&list=PLhQvP2JTFb...

[3] : GraphQL API creation : https://www.youtube.com/watch?v=qaLIpXe1gb0&list=PLhQvP2JTFb...

(full disclosure : Im the Founder of XgeneCloud)

kgraves
How does Parse compare to something like Firebase or Supabase?
muzani
I'm not sure about Supabase, but compared to Firebase...

Pros: Free, though you self-pay for server and MongoDB. Continuously improving. Much, much easier to set up for CRUD - I can get one up within half an hour. Web support seems better. Handles relations very well, whether it's one to one, many to many. God forbid you want to upload images direct to MongoDB, it handles that well. Integrates into some email adapters as well. The dashboard that accesses the DB is sexy and powerful, and has improved a lot since Facebook abandoned Parse.

Documentation is excellent, far better than Firebase. And the data belongs to you even if Firebase shuts down.

Cons: Self-hosted. Poor support. And won't land you any full yome jobs. Database is not real time unlike Firebase. Analytics and bug tracking is probably worse.

Similar: Cloud hosted functions, authentication. I don't remember if Firebase does sessions, but it handles that too, on web and apps.

In general, it's perfect for CRUD, especially on different range of apps and web.

muzani
Yeah, I still use Parse over Firebase in all my "full stack" work. I used to teach Firebase database to polytechnic students, and most of them had trouble with it even when given months. Parse Server was very easy to teach, and nearly all of them set it up within a day.
xrd
PouchDB is amazing. You can use their server side components and scale into couchdb later.
lukevp
There really isn’t a competitor. Supabase is trying to combine OSS tooling into a somewhat similar offering but it’s not nearly as feature rich as Firebase. That having been said, most people use Firebase for real time DB and auth, and Supabase supports that now. It doesn’t, however, support offline use cases, or any of the advanced functionality of firebase.

Pouch and couch solve the offline data scenario and live replication, but no auth story and the mapping of users to data is problematic (unless you build a proxy layer, there’s not an easy way to have some data be public, some private, and some shared).

Realm is paid these days, I believe, and it solves the data replication, but again, no auth.

__composed
Agreed and unfortunately Realm appears to have been acquired by mongo. No disrespect to the mongo team, but if we've learned anything from firebase it's that whenever a project like this gets acquired things get a little... shaky.
kiwicopple
Thanks for the mention lukevp.

I'm the founder of Supabase. We started this year, so we definitely have a lot more work to reach feature-parity with Firebase. Since we are using existing OSS products though, we're moving pretty fast.

We have made some technological decisions which we feel are better than firebase too. A developer sent us a note today that they converted a query from Firebase to Supabase and the result was a reduction from 27.9 seconds to 1.3 seconds. This is because we are building on top of Postgres. We also benchmarked our smallest servers yesterday - we were getting around 1200 reads/s on our smallest servers (FB was doing 1540 reads/s). We aim to get closer to 2K over the next 1 month and we'll publish the benchmarks.

> It doesn’t, however, support offline use cases

This is correct - it could take a few more months to get this out. Right now we're focused on stability/performance.

I'm happy to answer any other questions

stephen_cagle
I am excited about this. Two questions:

1) Does scaling a Supabase app basically just boil down to scaling a Postgres database? Firebase (Firestore) claims they can do like a million concurrent connections & 10 megs per second of writes. Any idea of the scaling limits of Supabase? Totally understand if this isn't on the radar yet, it is not really a concern for most applications.

2) Do you have a built in authentication solution? One of the pleasures of Firebase is the built in authentication that mostly just works by enabling it.

Happy that you are building an alternative to Firebase.

kiwicopple
> Does scaling a Supabase app basically just boil down to scaling a Postgres database?

Correct. We will soon add vertical/horizontal scaling (early next year). For concurrent connections, we use PostgREST[1] for RESTful calls, and an Elixir/Phoenix server [2] for realtime data. This reduces the number of connections to your DB, handling concurrency in the middleware. We are building the benchmarks now, but "enterprise scale" is top of mind with everything we are doing.

> Do you have a built in authentication solution?

Yes, we use GoTrue [3] for authentication, and we use Postgres Row Level Security for authorization. You can read more about it here: https://supabase.io/blog/2020/08/05/supabase-auth

[1] http://postgrest.org/en/v7.0.0/

[2] https://github.com/supabase/realtime

[3] https://github.com/netlify/gotrue

tjchear
Is there/will there be multi-tenant support for auth in Supabase?
kiwicopple
I may have misunderstood the question so feel free to push back if this doesn't make sense -

We use Postgres Row Level (RLS) security, so you can do some very advanced rules. For example, one of our team built a social network with PG and RLS: https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e...

RLS is flexible enough to cover multi-tenant scenarios, though it's up to you how you structure your schema to make it work.

tjchear
Are there plans to introduce an API similar to this then? https://cloud.google.com/identity-platform/docs/multi-tenanc...
kiwicopple
Interesting, I will have to investigate how this propagates through to their underlying database. I'm guessing this just changes where the data is being written inside a Firebase project?

There are several strategies for multi-tenancy in postgres. You can create a completely new database, a schema, or a have the tenancy as rules/logic in the same schema. I'd prefer the latter right now since RLS enables it so easily and it's more flexible - you can create the policies for your own tenancy structure.

kgraves
kiwicopple, really excited with how Supabase is coming along, definitely a need in the developer space to reduce reliance on Google services and Firebase is a big one, just a couple of questions:

1) Has there been anyone using Supabase in production?

2) I've seen on the website that it's currently in Alpha, If I was looking to use Supabase right now, I should expect breaking changes right?

3) Is a migration from Firebase to Supabase in the pipeline, this would certainly increase adoption.

Thanks for your work.

kiwicopple
Good questions.

> Has there been anyone using Supabase in production?

Yes, we're relatively stable now so the early adopters have been relaxed about using us in production. Our largest user is a scraping platform (https://www.monitoro.xyz), who have been great at stress testing (the team, and the platform). We're doing ~1M API calls/day right now. We will into Beta at the start of December once we've finished the load testing and security audits.

> If I was looking to use Supabase right now, I should expect breaking changes right?

You're best to wait for 2 weeks because we're about to do a PR [1] with some breaking changes [2] on the client library. It is a significantly better DX though, which the community really helped to improve. I'll merge this on Friday next week.

> Is a migration from Firebase to Supabase in the pipeline, this would certainly increase adoption

We have an issue on this one here [3]. We will look into this in December when we move out of alpha

[1] PR: https://github.com/supabase/supabase-js/pull/50

[2] Breaking changes: https://www.notion.so/supabase/Supabase-improved-DX-46907b88...

[3] Firebase migration: https://github.com/supabase/supabase/issues/175

tarun_anand
Firebase is an ecosystem of products. Which parts of firebase are your priority and what do you want to get done?
bribri
apollo, AWS Cognito, and AWS Appsync
stephen_cagle
Plug: I wrote a small clojurescript wrapper around firebase. You can try it out here. -> https://firemore.org/

I haven't found another solution that can get you started as quickly as Firebase can. Most common complaint I hear from developers about Firebase is the concern that Google will drop support at some point. I can't fault that concern, but Google seems to drop developer products at a much lower rate than customer products.

pier25
For the database and auth check FaunaDB.

It doesn't have sync or realtime yet, but it's a much better database overall.

exhibitapp
I second Fauna, it might not have all the bells and whistles yet, but they are excelling in providing a "serverless" database
pgt
I'm hedging my bets by using Datalog and the Datomic protocol wherever I can: https://tonsky.me/blog/datomic-as-protocol/

And keeping a close eye on Differential Dataflow: https://github.com/TimelyDataflow/differential-dataflow/

DD is commercialized in Materialize: https://materialize.io/

The solution is likely to arrive in the Clojure/ClojureScript ecosystem before it arrives anywhere else because tools like Datascript lend itself to this type of thinking, e.g. 3DF: https://github.com/sixthnormal/clj-3df/

The closest thing we have to streaming updates right now is FactUI, which uses the Clara rules engine, but it's IMO hampered by limitations of Clara and Cljs namespacing: https://github.com/arachne-framework/factui

The RETE algorithm is a less general solution to incremental updates. Zach Oakes is doing some interesting work with O'Doyle Rules: https://github.com/oakes/odoyle-rules