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)
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?
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)
What are the current scaling limitations of Supabase? Do you have a sense of how many req/s etc it can handle? Firebase has the nice property that it's really easy to get started but it will scale to millions of users (ignoring the dev cost of restricted querying), I'm curious how that will work with managed Postgres.
Are there any plans for a typed/generated client down the line?
I see I replied to that tweet - it's a great list of criteria.
> What are the current scaling limitations of Supabase?
We haven't benchmarked it yet, but we have one of our power users doing ~1M API calls per week. That's on a t3a micro server. Soon, we will give you the ability to scale up and out. We don't plan to abstract away the database layer too heavily because it break the "no lockin" promise. We will more likely make it very easy to run a High Availability cluster (Ant has a background in HA).
> Are there any plans for a typed/generated client down the line?
100%. We're planning a Supabase CLI which will do this (+ give you the ability to spin up new projects etc).
I really like the open source approach. I hope you guys don't limit necessary features like few of the other tools in this area to saas model.
Really neat to see elixir shining. :)
Feature request time:
Firebase don't really have rate limiting (unless you want to implement it with after and make a mess). That would be neat to have.
Analytics. Don't need anything too complex. I can't use analytics part of firebase because that's blocked by many browsers and increasing. Plus, I don't like sharing data with cough.
This shouldn't be too hard. We use Kong which has rate-limiting plugins
> Analytics. Don't need anything too complex
I've never used Firebase's analytics, but it seems like we could do something fairly simple if there is enough demand for it. There are already some very feature-rich self-hosted tools in this space (like PostHog) though. Any reason why you wouldn't want to use those tools?
As for the reason, maintenance and integration. I only need aggregated insight into traffic such as location (country/state), heat spots on the supabase parts (auth, database), referrers, etc. Most of what I need could be inferred from the logs.
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.
The team really loves what we're working on so an acquisition isn't something we want. In fact, we feel that Firebase probably could have provided a lot more innovation in the DB space, but perhaps Google limited their product offering to things which were strategically aligned to Google. We really value the freedom we have to build exactly what we (and our users) want.
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!
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), but it will require a bit of re-engineering on our end, so we will continue to focus on the backend features first.
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.
> 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
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.
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.
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
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
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.
"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.
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.
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.
> But why can Postgres not be promoted to the "application level"?
Anything is possible. It can be done. My personal/professional opinion is that you are shooting yourself in the foot by eliminating what is otherwise a very handy abstraction between your business machinery and the underlying system that stores the data.
That’s not really a handy abstraction though, because you ain’t gonna need it. The exception being you scale past Postgres in which case you’re going to need a new architecture anyway. Way better to leverage the robust tooling that Postgres provides rather than rolling your own. Bravo to Supabase for having the technical insight to bring that leverage to the mainstream.
It's worth noting that you don't _have_ to use RLS. This just give you the option to if you don't want to do it on the application level (like Firebase).
You should try it out though - it's very cool when you see it in action
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?
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
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!
We're using Netlify's 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.
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.
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.
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/). 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.
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!
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
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!
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.
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
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
[2] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
[3] PostgREST auth: http://postgrest.org/en/v7.0.0/auth.html
[4] Policies: https://www.postgresql.org/docs/current/sql-createpolicy.htm...
[5] Social network: https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e...
[6] GoTrue: https://github.com/netlify/gotrue