7 ms·

Auth is now available in Supabase (YC S20)

173 points by kiwicopple 6y ago

kiwicopple 6y ago
Ant & I are excited to release Supabase Auth. Supabase is an open source Firebase alternative. We are building the features of Firebase using scalable, open source products. Back in May one of our users unexpectedly launched us on Hacker News[1]. There were a lot of comments about Auth: many people asking for it, and many wondering how we would implement it. If you don’t care for the details, the linked blog post is more high-level. For anyone interested in the technical details, this is how we implemented our Auth system from the bottom up: Authorization: Supabase is built with Postgres + PostgREST so we were adamant that we’d use PostgreSQL’s row level security[2] for authorization. PostgREST solves most of the hard work with their auth system[3] and Supabase hides the PostgREST implementation when you start a new project. We create a few roles in your database: one “anon” role which is restricted, and one “authenticated” role which users can “assume” once they are logged in. Inside your database, you can then add Postgres Policies[4]. These are incredibly powerful (see Steve’s “social network” database[5]). Admittedly they can be confusing, but we have plans to make them simple. Their flexibility outweighs their complexity in any case. Authentication: After trying many open source tools, we found Netlify’s GoTrue[6]. This was simple and covered most of the functionality we need. There are some missing Oauth clients, so we will contribute them when we roll out Oauth (we only have email login for now). When a user starts a new Supabase project, we create an “auth” schema in their database. GoTrue stores the users and user data in this schema. AuthN+AuthZ: when a user signs up to your app/project, GoTrue assigns them a unique UID, saves them in the auth schema, and returns a JWT with the user’s details. Our client library attached this JWT to every API request. PostgREST validates the JWT then sends the request through to Postgres. Postgres is able to inspect the request header to get the user’s role and UID, but to make this easy we added some helper functions to the auth schema: one to get the logged in user’s UID (`auth.uid()`) and one to get the logged in user’s role (`auth.role()`). These functions can be used in the Postgres Policies to create a very powerful rules engine. Postgres is one of those tools which you love the more you use it. RLS+Policies are no exception here. It’s very cool being able to specify rules in your database and then be carefree in your frontend. We hope you’ll try it out and send feedback. Note - we’re still in alpha! Please be lenient :). There are some missing features (we’ll be enabling email confirmations/password reset in 1 or 2 weeks) [1] Previous Launch: https://news.ycombinator.com/item?id=23319901 https://news.ycombinator.com/item?id=23319901 [2] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [3] PostgREST auth: http://postgrest.org/en/v7.0.0/auth.html http://postgrest.org/en/v7.0.0/auth.html [4] Policies: https://www.postgresql.org/docs/current/sql-createpolicy.html https://www.postgresql.org/docs/current/sql-createpolicy.htm... [5] Social network: https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/users.sql#L65-L80 https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e... [6] GoTrue: https://github.com/netlify/gotrue https://github.com/netlify/gotrue
- an_opabinia 6y ago
  It looks like your client takes a URL that points to your domain. Is there open source code that runs that URL? In other words, did you open source the part of the application the client connects to?
  - kiwicopple 6y ago
    At the moment no: https://supabase.io/docs/faq#how-do-i-host-supabase https://supabase.io/docs/faq#how-do-i-host-supabase When we get out of alpha, we will release a fat middleware server which stitches together the the open source tools we are using. Firebase isn't just "one thing", which will make it increasingly difficult to pack into a single server as we grow, so it might end up being several servers split up by feature. Here are all the tools we use: https://supabase.io/docs/#how-it-works https://supabase.io/docs/#how-it-works
- nicoburns 6y ago
  Supabase is pretty exciting. Our product at work was initially hosted on Firebase, and while there were some really nice aspects to it (auth, realtime querying) we had a whole host of problems with the limited querying power of Firebase's non-relational model. So we've gradually been porting everything over to Postgres (with Hasura for realtime queries). I have a question about the new auth functionality: In the blog post it shows configuring auth rules via a GUI. Is there also support for a code-first approach where these rules are stored in a (sanely human editable) text format, which is then synced up to the server via a CLI or similar. I've found that this is absolutely crucial in order to ensure consistency between dev and prod environments, and to be able to spin up testing environments. For that matter, is there an easy way to run the superbase stack locally as a local dev environment?
  - kiwicopple 6y ago
    > Is there also support for a code-first approach We plan to build git integrations which will handle migrations (including Policies) and two-way syncing between git and postgres. For now, you'd have to handle this yourself (we give you root access to your Postgres database) > is there an easy way to run the superbase stack locally We had(have) a docker image but it's outdated. We're in the process of updating for local development. It handles the middleware, but not the UI (for now)
TheTank 6y ago
Congrats on launching. It looks like it’s only email login. Do you have an idea when you will release Oauth logins?
- kiwicopple 6y ago
  We're using Netlify's GoTrue (https://github.com/netlify/gotrue https://github.com/netlify/gotrue) for logins. For the providers they already support (bitbucket, github, gitlab, and google) we are aiming to release this month. For other logins, we will contribute back to the repo wherever there is demand.
goleary 6y ago
just an FYI: the first key in the search command shows up as an empty key on Windows (chrome). So it almost looks like you should hit Space + K even though I see its actually Control + K.
- kiwicopple 6y ago
  Nice one. The site is built with Docusaurus (v2) - I just upgraded it today to the new search functionality. I'll fix soon
webel0 6y ago
Good on you guys for listening and putting out what seems to be some pretty awesome auth! Row level security is far more than I was expecting but exactly the sort of thing that is needed in a lot of my applications. I look forward to diving into this more.
lukevp 6y ago
Congrats on adding Auth! Auth + observable data changes + real-time syncing with row level security in something self-hosted is awesome. Is there a concept in Supabase of offline data creation, or is it online only? The offline support of Firebase is really great for a lot of apps where users create the data (or for example, collecting gps coordinates of a truck). Anything that doesn’t require an external validator or datasource. I feel this is a drastically underserved market. I wouldn’t ever use Firebase and delegate all hosting and scaling of my application to a 3rd party with a tight coupling all the way down to the front end, without some type of escape hatch. The way Supabase is a composition of OSS components is really brilliant!
- kiwicopple 6y ago
  We'd love to build an offline/online solution. It's a bit complex when you start dealing with conflict resolution but we are already looking at a few possible OSS libraries to deal with this. At the moment the leading contender is RxDB (https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb), but it will require a bit of re-engineering on our end, so we will continue to focus on the backend features first.
  - lukevp 6y ago
    Sounds great, please reach out to me on this from my profile if you’d like to discuss further. I’ve been using CouchDB/PouchDB for a product, and have worked with RxDB and Realm as well. RxDB has schemas which may mesh better with your backend architecture. I think schema-based is the right way to go personally. Would be great if the TS definitions could be generated automatically from the backend with automatic migrations of local data so it doesn’t have to be replicated again. Do you have the concept of ephemeral data (data that is not needed for persistence) or is everything persisted? One example of ephemeral data would be the users online in a given channel, or the position and range of a shared cursor in a document collaboration.
    - kiwicopple 6y ago
      > Would be great if the TS definitions could be generated automatically We're working on this! Watch this space > Do you have the concept of ephemeral data Everything is persisted right now, so the realtime functionality probably wont' be great for tracking things like mouse positions. Not sure if we will ever support ephemeral data, but we really just go where our users ask us. If there's enough demand, we'll build
gdeglin 6y ago
Congrats on the launch! I'm a big fan of your approach of making this open source and deeply leveraging PostgreSQL.
enumjorge 6y ago
This is awesome. Auth is such a pain and one of the biggest perks of Firebase for me. Could you share more details on why you decided to go with GoTrue? I’m interested in how it stacked up against the alternatives you looked at.
- kiwicopple 6y ago
  We checked out a lot of tools and built POC's with Kratos and KeyCloak Kratos was very promising but too new/unstable. We spent a lot of time with KeyCloak, but it had some very heavy server requirements. We want to be able to release Supabase as a single docker image and it would have been too difficult with KeyCloak. We chose GoTrue because it's fairly stable and feature rich, and backed by Netlify so it's well supported. They didn't have PG support, so we had to fork it, but otherwise it's been great.
kbyatnal 6y ago
"With policies, your database becomes the rules engine. Instead of repetitively filtering your queries, you can simply define a rule on your database table, auth.uid() = user_id, and your request will return the rows which pass the rule, even when you remove the filter from your middleware." I'm not sure how I feel about this. With something like authorization, being explicit is better than implicit. This makes it far too easy for someone to accidentally forget a policy configuration, but it looks like all your other queries so it passes code review, and now you have a data breach. But could be that I'm missing something in how this actually works. Would love to get your thoughts on it.
- whalesalad 6y ago
  I agree. I would not secure user data with row-level security inside the DB itself. That’s an application concern and it should live in your application layer. It also limits you from replacing the underlying storage engine later on, if you decide PostgreSQL is not the answer. I find this to be an unwise architectural decision.
  - rvense 6y ago
    But why can Postgres not be promoted to the "application level"? If you combine it with a few extra tools like an auth service and an HTTP API adapter, the need for custom backend code is reduced or removed. Your backend is created declaratively through the schema and policies can be exposed directly to clients. I have been thinking about this a lot, recently, due to working on a greenfields project where I was allowed to think all the foundational architectural decisions of my past projects through. It's struck me how much of the tedious code I've written in my career has been due to a few features in database systems that were either missing or unknown to me (mainly related to auth and validation). Supabase is exactly the kind of system I have been working towards. You can use Postgres as a dumb datastore, but you'll be replicating a lot of functionality at the "application level" that Postgres already has. And if you're serious about being able to swap it out for another database, you'll either be writing a lot of abstractions, or foregoing some of its great features (e.g. its JSON datatypes) in order to not become too joined to it. Creating more work for yourself due to some unknown situation that might arise in the future strikes me as an even more unwise decision than tying yourself to a flexible, well-known, and proven open source project. It seems no different than tying yourself to React or Docker or whatever.
sali0 6y ago
Really excited about this. I was going to choose Firebase for a new project of mine but I really hate the inevitable coupling. I am very interested in using your product, but I am very much a noob at Postgres. How much Postgres knowledge would be needed to make use of your product? I do plan to learn as much as I can about it, but I wanted to get your thoughts. Will you be releasing docs with regards to prerequisite Postgres knowledge, or at least links to what may be useful to know?
- kiwicopple 6y ago
  We started with the UI because we want to make it simple for anyone to get started. Our task is to make it so that you don't need any knowledge of Postgres to get started. One of the things I'm excited about is our table view - it's just as you would expect from a database client, but functions more like Airtable. You will be able to create tables/rows/columns like you would in a spreadsheet. We still have a lot of work to do to simplify Postgres, but in a few more months we think we will have something that even non-techies can use
- deleted 6y ago
  [deleted]
FanaHOVA 6y ago
I was always too lazy to add auth to this: https://captable.645ventures.com/ https://captable.645ventures.com/ I might try and do it with Supabase! It's 100% client side right now so it seems like a good fit. Will report on it when I get a chance to fiddle around with it. Congrats on shipping!
contravariant 6y ago
Maybe I'm just not the target audience, but I'm still somewhat confused on what supabase actually is. All I could find was that it was firebase but open source, which tells me nothing as I'm not overly familiar with firebase (and firebase's description didn't help me understand which parts supabase tries to replicate). Literally the only way I could become familiar with firebase enough to understand how this is a good alternative is if I decide not to use supabase and go with firebase instead.
- awalias 6y ago
  we provide a layer on top of postgres which includes: auto-generated CRUD apis that update as you change your schema, a realtime api so you can listen to all the changes happening in your database over websockets, and now an auth system to register users and control which data they have access to without having to write any middleware what it boils down to is writing apis and connector code to your database can be a laborious process - we're automating that part away
  - contravariant 6y ago
    So am I right in thinking it's essentially an SDK for building CRUD web applications?
    - ies7 6y ago
      My experience with supabase start with their realtime server. An Elixir server (Phoenix) that allows you to listen to changes in your database via websockets. It’s like Postgresql Notify with some extra features like Debezium+Kafka
- kanobo 6y ago
  It is a database you can easily update and watch for changes in your website's javascript. Now you can also log people in with the same service. With those two you can move much of the logic that was traditionally done on the server onto the client-side.
kanobo 6y ago
It's ironic (but understandable) that Supabase uses auth0 for their auth. How does Supabase auth compare to just using auth0?
- kiwicopple 6y ago
  We're a big fan of dogfooding - everything in Supabase is built with Supabase except (as you correctly point out) the Auth. > How does Supabase auth compare to just using auth0? Supabase Auth is the result of only 6 weeks of development, so we have a long way to go to catch up with Auth0 features/stability. We'll get there though!
eatonphil 6y ago
Been working on a similar project [0] with a simpler architecture. You supply a database schema and the project builds you a browser UI and API with authentication, filtering, pagination, etc. Authorization is tricky though. I've been looking into high-level compile-to-SQL languages like TreSQL [1] for expressing more complex logic (e.g. `notes.get.require: notes.is_public OR (notes->organization.id = $user.id)`). There's some thinking to be done to flesh out a good language for expressing policies tied to a user session in SQL. [0] https://www.dbcore.org/ https://www.dbcore.org/ [1] https://github.com/mrumkovskis/tresql https://github.com/mrumkovskis/tresql
agustif 6y ago
Is graphql support on the roadmap? Why did you go with elixir for subscriptions?
- kiwicopple 6y ago
  At this stage we don't have plans to support GraphQL. We're a small team so we have to be very strategic which technologies we choose to maintain velocity. Since we use PostgREST, we already support many of the key benefits of GraphQL[1]. That being said, we're big fans of Graphile (https://www.graphile.org/ https://www.graphile.org/). Even if we don't support it ourselves, it would be simple for any dev to point graphile to the Postgres instance and get a "free" graphql API. > Why did you go with elixir for subscriptions? I actually built the realtime server last year to replace Firebase. I needed websockets (it was for a chat app), so elixir (Phoenix) was the right tool for the job. [1] Resource embedding: http://postgrest.org/en/v7.0.0/api.html#resource-embedding http://postgrest.org/en/v7.0.0/api.html#resource-embedding
  - agustif 6y ago
    Yeah that makes total sense (focusing on strategic tech). Also hadn't thought about plugging in graphile, I guess that makes sense. I also saw in the repo you don't have TS in mind for now (It could be great later down with a big codebase) I'm small contributor to an accounts javascript package (AccountsJS), it can be used with different dattabases (Mongo, TypeORM, Redis, etc), and transports (Rest, GraphQL) In case you might wanna consider it in the future!
    - agustif 6y ago
      On the elixir/phoenix choice for WS, I guess that makes sense too, I diped my toes on eelixir a long time ago after starting learning to code with ruby. It was cool, but I found a better home at JS/TS. You can have WS with graphql-subscriptions and postgresql-subscriptions for example too, all in node/js and frontend with apollo / react or vue or angular what you like
oskarahl 6y ago
Love the feature preview videos, what did you use to create them?
- kiwicopple 6y ago
  It's called Glitterly - glitterly.app I saw it on a ShowHN the other day and took a mental note to try it so I could give the founder feedback. It was very easy to use, definitely recommended. Also check out this one (on ShowHN now) if you need something more feature rich: https://storycreatorapp.com https://storycreatorapp.com

173 points by kiwicopple 6y ago

Ant & I are excited to release Supabase Auth. Supabase is an open source Firebase alternative. We are building the features of Firebase using scalable, open source products. Back in May one of our users unexpectedly launched us on Hacker News[1]. There were a lot of comments about Auth: many people asking for it, and many wondering how we would implement it. If you don’t care for the details, the linked blog post is more high-level. For anyone interested in the technical details, this is how we implemented our Auth system from the bottom up: Authorization: Supabase is built with Postgres + PostgREST so we were adamant that we’d use PostgreSQL’s row level security[2] for authorization. PostgREST solves most of the hard work with their auth system[3] and Supabase hides the PostgREST implementation when you start a new project. We create a few roles in your database: one “anon” role which is restricted, and one “authenticated” role which users can “assume” once they are logged in. Inside your database, you can then add Postgres Policies[4]. These are incredibly powerful (see Steve’s “social network” database[5]). Admittedly they can be confusing, but we have plans to make them simple. Their flexibility outweighs their complexity in any case. Authentication: After trying many open source tools, we found Netlify’s GoTrue[6]. This was simple and covered most of the functionality we need. There are some missing Oauth clients, so we will contribute them when we roll out Oauth (we only have email login for now). When a user starts a new Supabase project, we create an “auth” schema in their database. GoTrue stores the users and user data in this schema. AuthN+AuthZ: when a user signs up to your app/project, GoTrue assigns them a unique UID, saves them in the auth schema, and returns a JWT with the user’s details. Our client library attached this JWT to every API request. PostgREST validates the JWT then sends the request through to Postgres. Postgres is able to inspect the request header to get the user’s role and UID, but to make this easy we added some helper functions to the auth schema: one to get the logged in user’s UID (`auth.uid()`) and one to get the logged in user’s role (`auth.role()`). These functions can be used in the Postgres Policies to create a very powerful rules engine. Postgres is one of those tools which you love the more you use it. RLS+Policies are no exception here. It’s very cool being able to specify rules in your database and then be carefree in your frontend. We hope you’ll try it out and send feedback. Note - we’re still in alpha! Please be lenient :). There are some missing features (we’ll be enabling email confirmations/password reset in 1 or 2 weeks) [1] Previous Launch: https://news.ycombinator.com/item?id=23319901 https://news.ycombinator.com/item?id=23319901 [2] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [3] PostgREST auth: http://postgrest.org/en/v7.0.0/auth.html http://postgrest.org/en/v7.0.0/auth.html [4] Policies: https://www.postgresql.org/docs/current/sql-createpolicy.html https://www.postgresql.org/docs/current/sql-createpolicy.htm... [5] Social network: https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/users.sql#L65-L80 https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e... [6] GoTrue: https://github.com/netlify/gotrue https://github.com/netlify/gotrue

an_opabinia 6y ago
It looks like your client takes a URL that points to your domain. Is there open source code that runs that URL? In other words, did you open source the part of the application the client connects to?
- kiwicopple 6y ago
  At the moment no: https://supabase.io/docs/faq#how-do-i-host-supabase https://supabase.io/docs/faq#how-do-i-host-supabase When we get out of alpha, we will release a fat middleware server which stitches together the the open source tools we are using. Firebase isn't just "one thing", which will make it increasingly difficult to pack into a single server as we grow, so it might end up being several servers split up by feature. Here are all the tools we use: https://supabase.io/docs/#how-it-works https://supabase.io/docs/#how-it-works
nicoburns 6y ago
Supabase is pretty exciting. Our product at work was initially hosted on Firebase, and while there were some really nice aspects to it (auth, realtime querying) we had a whole host of problems with the limited querying power of Firebase's non-relational model. So we've gradually been porting everything over to Postgres (with Hasura for realtime queries). I have a question about the new auth functionality: In the blog post it shows configuring auth rules via a GUI. Is there also support for a code-first approach where these rules are stored in a (sanely human editable) text format, which is then synced up to the server via a CLI or similar. I've found that this is absolutely crucial in order to ensure consistency between dev and prod environments, and to be able to spin up testing environments. For that matter, is there an easy way to run the superbase stack locally as a local dev environment?
- kiwicopple 6y ago
  > Is there also support for a code-first approach We plan to build git integrations which will handle migrations (including Policies) and two-way syncing between git and postgres. For now, you'd have to handle this yourself (we give you root access to your Postgres database) > is there an easy way to run the superbase stack locally We had(have) a docker image but it's outdated. We're in the process of updating for local development. It handles the middleware, but not the UI (for now)

TheTank 6y ago

Congrats on launching. It looks like it’s only email login. Do you have an idea when you will release Oauth logins?

kiwicopple 6y ago
We're using Netlify's GoTrue (https://github.com/netlify/gotrue https://github.com/netlify/gotrue) for logins. For the providers they already support (bitbucket, github, gitlab, and google) we are aiming to release this month. For other logins, we will contribute back to the repo wherever there is demand.

goleary 6y ago

just an FYI: the first key in the search command shows up as an empty key on Windows (chrome). So it almost looks like you should hit Space + K even though I see its actually Control + K.

kiwicopple 6y ago
Nice one. The site is built with Docusaurus (v2) - I just upgraded it today to the new search functionality. I'll fix soon

webel0 6y ago

Good on you guys for listening and putting out what seems to be some pretty awesome auth! Row level security is far more than I was expecting but exactly the sort of thing that is needed in a lot of my applications. I look forward to diving into this more.

lukevp 6y ago

Congrats on adding Auth! Auth + observable data changes + real-time syncing with row level security in something self-hosted is awesome. Is there a concept in Supabase of offline data creation, or is it online only? The offline support of Firebase is really great for a lot of apps where users create the data (or for example, collecting gps coordinates of a truck). Anything that doesn’t require an external validator or datasource. I feel this is a drastically underserved market. I wouldn’t ever use Firebase and delegate all hosting and scaling of my application to a 3rd party with a tight coupling all the way down to the front end, without some type of escape hatch. The way Supabase is a composition of OSS components is really brilliant!

kiwicopple 6y ago
We'd love to build an offline/online solution. It's a bit complex when you start dealing with conflict resolution but we are already looking at a few possible OSS libraries to deal with this. At the moment the leading contender is RxDB (https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb), but it will require a bit of re-engineering on our end, so we will continue to focus on the backend features first.
- lukevp 6y ago
  Sounds great, please reach out to me on this from my profile if you’d like to discuss further. I’ve been using CouchDB/PouchDB for a product, and have worked with RxDB and Realm as well. RxDB has schemas which may mesh better with your backend architecture. I think schema-based is the right way to go personally. Would be great if the TS definitions could be generated automatically from the backend with automatic migrations of local data so it doesn’t have to be replicated again. Do you have the concept of ephemeral data (data that is not needed for persistence) or is everything persisted? One example of ephemeral data would be the users online in a given channel, or the position and range of a shared cursor in a document collaboration.
  - kiwicopple 6y ago
    > Would be great if the TS definitions could be generated automatically We're working on this! Watch this space > Do you have the concept of ephemeral data Everything is persisted right now, so the realtime functionality probably wont' be great for tracking things like mouse positions. Not sure if we will ever support ephemeral data, but we really just go where our users ask us. If there's enough demand, we'll build

gdeglin 6y ago

Congrats on the launch! I'm a big fan of your approach of making this open source and deeply leveraging PostgreSQL.

enumjorge 6y ago

This is awesome. Auth is such a pain and one of the biggest perks of Firebase for me. Could you share more details on why you decided to go with GoTrue? I’m interested in how it stacked up against the alternatives you looked at.

kiwicopple 6y ago
We checked out a lot of tools and built POC's with Kratos and KeyCloak Kratos was very promising but too new/unstable. We spent a lot of time with KeyCloak, but it had some very heavy server requirements. We want to be able to release Supabase as a single docker image and it would have been too difficult with KeyCloak. We chose GoTrue because it's fairly stable and feature rich, and backed by Netlify so it's well supported. They didn't have PG support, so we had to fork it, but otherwise it's been great.

kbyatnal 6y ago

"With policies, your database becomes the rules engine. Instead of repetitively filtering your queries, you can simply define a rule on your database table, auth.uid() = user_id, and your request will return the rows which pass the rule, even when you remove the filter from your middleware." I'm not sure how I feel about this. With something like authorization, being explicit is better than implicit. This makes it far too easy for someone to accidentally forget a policy configuration, but it looks like all your other queries so it passes code review, and now you have a data breach. But could be that I'm missing something in how this actually works. Would love to get your thoughts on it.

whalesalad 6y ago
I agree. I would not secure user data with row-level security inside the DB itself. That’s an application concern and it should live in your application layer. It also limits you from replacing the underlying storage engine later on, if you decide PostgreSQL is not the answer. I find this to be an unwise architectural decision.
- rvense 6y ago
  But why can Postgres not be promoted to the "application level"? If you combine it with a few extra tools like an auth service and an HTTP API adapter, the need for custom backend code is reduced or removed. Your backend is created declaratively through the schema and policies can be exposed directly to clients. I have been thinking about this a lot, recently, due to working on a greenfields project where I was allowed to think all the foundational architectural decisions of my past projects through. It's struck me how much of the tedious code I've written in my career has been due to a few features in database systems that were either missing or unknown to me (mainly related to auth and validation). Supabase is exactly the kind of system I have been working towards. You can use Postgres as a dumb datastore, but you'll be replicating a lot of functionality at the "application level" that Postgres already has. And if you're serious about being able to swap it out for another database, you'll either be writing a lot of abstractions, or foregoing some of its great features (e.g. its JSON datatypes) in order to not become too joined to it. Creating more work for yourself due to some unknown situation that might arise in the future strikes me as an even more unwise decision than tying yourself to a flexible, well-known, and proven open source project. It seems no different than tying yourself to React or Docker or whatever.

sali0 6y ago

Really excited about this. I was going to choose Firebase for a new project of mine but I really hate the inevitable coupling. I am very interested in using your product, but I am very much a noob at Postgres. How much Postgres knowledge would be needed to make use of your product? I do plan to learn as much as I can about it, but I wanted to get your thoughts. Will you be releasing docs with regards to prerequisite Postgres knowledge, or at least links to what may be useful to know?

kiwicopple 6y ago
We started with the UI because we want to make it simple for anyone to get started. Our task is to make it so that you don't need any knowledge of Postgres to get started. One of the things I'm excited about is our table view - it's just as you would expect from a database client, but functions more like Airtable. You will be able to create tables/rows/columns like you would in a spreadsheet. We still have a lot of work to do to simplify Postgres, but in a few more months we think we will have something that even non-techies can use
deleted 6y ago
[deleted]

FanaHOVA 6y ago

I was always too lazy to add auth to this: https://captable.645ventures.com/ https://captable.645ventures.com/ I might try and do it with Supabase! It's 100% client side right now so it seems like a good fit. Will report on it when I get a chance to fiddle around with it. Congrats on shipping!

contravariant 6y ago

Maybe I'm just not the target audience, but I'm still somewhat confused on what supabase actually is. All I could find was that it was firebase but open source, which tells me nothing as I'm not overly familiar with firebase (and firebase's description didn't help me understand which parts supabase tries to replicate). Literally the only way I could become familiar with firebase enough to understand how this is a good alternative is if I decide not to use supabase and go with firebase instead.

awalias 6y ago
we provide a layer on top of postgres which includes: auto-generated CRUD apis that update as you change your schema, a realtime api so you can listen to all the changes happening in your database over websockets, and now an auth system to register users and control which data they have access to without having to write any middleware what it boils down to is writing apis and connector code to your database can be a laborious process - we're automating that part away
- contravariant 6y ago
  So am I right in thinking it's essentially an SDK for building CRUD web applications?
  - ies7 6y ago
    My experience with supabase start with their realtime server. An Elixir server (Phoenix) that allows you to listen to changes in your database via websockets. It’s like Postgresql Notify with some extra features like Debezium+Kafka
kanobo 6y ago
It is a database you can easily update and watch for changes in your website's javascript. Now you can also log people in with the same service. With those two you can move much of the logic that was traditionally done on the server onto the client-side.

kanobo 6y ago

It's ironic (but understandable) that Supabase uses auth0 for their auth. How does Supabase auth compare to just using auth0?

kiwicopple 6y ago
We're a big fan of dogfooding - everything in Supabase is built with Supabase except (as you correctly point out) the Auth. > How does Supabase auth compare to just using auth0? Supabase Auth is the result of only 6 weeks of development, so we have a long way to go to catch up with Auth0 features/stability. We'll get there though!

eatonphil 6y ago

Been working on a similar project [0] with a simpler architecture. You supply a database schema and the project builds you a browser UI and API with authentication, filtering, pagination, etc. Authorization is tricky though. I've been looking into high-level compile-to-SQL languages like TreSQL [1] for expressing more complex logic (e.g. `notes.get.require: notes.is_public OR (notes->organization.id = $user.id)`). There's some thinking to be done to flesh out a good language for expressing policies tied to a user session in SQL. [0] https://www.dbcore.org/ https://www.dbcore.org/ [1] https://github.com/mrumkovskis/tresql https://github.com/mrumkovskis/tresql

agustif 6y ago

Is graphql support on the roadmap? Why did you go with elixir for subscriptions?

kiwicopple 6y ago
At this stage we don't have plans to support GraphQL. We're a small team so we have to be very strategic which technologies we choose to maintain velocity. Since we use PostgREST, we already support many of the key benefits of GraphQL[1]. That being said, we're big fans of Graphile (https://www.graphile.org/ https://www.graphile.org/). Even if we don't support it ourselves, it would be simple for any dev to point graphile to the Postgres instance and get a "free" graphql API. > Why did you go with elixir for subscriptions? I actually built the realtime server last year to replace Firebase. I needed websockets (it was for a chat app), so elixir (Phoenix) was the right tool for the job. [1] Resource embedding: http://postgrest.org/en/v7.0.0/api.html#resource-embedding http://postgrest.org/en/v7.0.0/api.html#resource-embedding
- agustif 6y ago
  Yeah that makes total sense (focusing on strategic tech). Also hadn't thought about plugging in graphile, I guess that makes sense. I also saw in the repo you don't have TS in mind for now (It could be great later down with a big codebase) I'm small contributor to an accounts javascript package (AccountsJS), it can be used with different dattabases (Mongo, TypeORM, Redis, etc), and transports (Rest, GraphQL) In case you might wanna consider it in the future!
  - agustif 6y ago
    On the elixir/phoenix choice for WS, I guess that makes sense too, I diped my toes on eelixir a long time ago after starting learning to code with ruby. It was cool, but I found a better home at JS/TS. You can have WS with graphql-subscriptions and postgresql-subscriptions for example too, all in node/js and frontend with apollo / react or vue or angular what you like

oskarahl 6y ago

Love the feature preview videos, what did you use to create them?

kiwicopple 6y ago
It's called Glitterly - glitterly.app I saw it on a ShowHN the other day and took a mental note to try it so I could give the founder feedback. It was very easy to use, definitely recommended. Also check out this one (on ShowHN now) if you need something more feature rich: https://storycreatorapp.com https://storycreatorapp.com