5 ms·

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. Tha

by lukevp 6y ago

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 6y ago
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 6y ago
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 6y ago
  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 6y ago
    > 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 https://supabase.io/blog/2020/08/05/supabase-auth [1] http://postgrest.org/en/v7.0.0/ http://postgrest.org/en/v7.0.0/ [2] https://github.com/supabase/realtime https://github.com/supabase/realtime [3] https://github.com/netlify/gotrue https://github.com/netlify/gotrue
- tjchear 6y ago
  Is there/will there be multi-tenant support for auth in Supabase?
  - kiwicopple 6y ago
    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/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/posts.sql#L67-L82 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 6y ago
      Are there plans to introduce an API similar to this then? https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication https://cloud.google.com/identity-platform/docs/multi-tenanc...
      - kiwicopple 6y ago
        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 6y ago
  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 6y ago
    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 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 https://github.com/supabase/supabase-js/pull/50 [2] Breaking changes: https://www.notion.so/supabase/Supabase-improved-DX-46907b88d337471791bc9b8104ecba39 https://www.notion.so/supabase/Supabase-improved-DX-46907b88... [3] Firebase migration: https://github.com/supabase/supabase/issues/175 https://github.com/supabase/supabase/issues/175

by lukevp 6y ago

__composed 6y ago

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 6y ago

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 6y ago
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 6y ago
  > 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 https://supabase.io/blog/2020/08/05/supabase-auth [1] http://postgrest.org/en/v7.0.0/ http://postgrest.org/en/v7.0.0/ [2] https://github.com/supabase/realtime https://github.com/supabase/realtime [3] https://github.com/netlify/gotrue https://github.com/netlify/gotrue
tjchear 6y ago
Is there/will there be multi-tenant support for auth in Supabase?
- kiwicopple 6y ago
  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/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/posts.sql#L67-L82 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 6y ago
    Are there plans to introduce an API similar to this then? https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication https://cloud.google.com/identity-platform/docs/multi-tenanc...
    - kiwicopple 6y ago
      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 6y ago
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 6y ago
  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 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 https://github.com/supabase/supabase-js/pull/50 [2] Breaking changes: https://www.notion.so/supabase/Supabase-improved-DX-46907b88d337471791bc9b8104ecba39 https://www.notion.so/supabase/Supabase-improved-DX-46907b88... [3] Firebase migration: https://github.com/supabase/supabase/issues/175 https://github.com/supabase/supabase/issues/175