Ask HN: The state of Firebase alternatives in 2020?
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.
Has there been any strides in this area and what is the current state of them in 2020?
Thanks.
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.
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
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.
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/
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.
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.
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.
> 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
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)
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.
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
Differential Dataflow + Datomic solves this problem.
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.
It doesn't have sync or realtime yet, but it's a much better database overall.