Supabase redwood experiments


Supabase, for those who don’t know, is an alternative to Firebase that’s open source and built on top of PostgreSQL. It’s new, so it can’t do a fraction of what Firebase does, but what it already does do is pretty awesome!

Earlier today I tried using it with Redwood.

Experiment 1

My first experiment was to use supabase, instead of Heroku, as the “production” db for the Redwood tutorial.


Worked great, and was super easy to get going.
Creating a post using the scaffolded CRUD stuff from the tutorial, and it immediately shows up in the supabase webinterface, and vice versa

If you want to try it out yourself, you just have to create a project on supabase and get your DB’s connection info, and use that as DATABASE_URL in your Netlify setup

Demo links

The code for the blog is below, but there is not much to look at really. All the “magic” is in the DATABASE_URL env var, and that’s secret and only visible on Netlify

Experiment 2

Supabase launched auth support a while ago, and with that they also published a “slack clone” as a demo showcasing both the auth stuff, but also the real-time capabilities of supabase. The demo is written using Next and is deployed to Vercel. I ported it over to Redwood and it was actually way less work than I feared :slight_smile:

This is their gif to show it off. I could create my own, but why bother, it’d look exactly the same :stuck_out_tongue:

This is what the users table look like (on my cellphone)

Their auth stuff is built using Netlify’s GoTrue

Demo links

The code is linked below, but before you look at it I do have to warn you that I touched as little as possible of their original code. So it’s a mix of 100 different coding styles, because that’s what they had… Just so you know.


Woah, nice work @Tobbe :rocket:

Did you see this topic from May? Seems like the OP is from the Supabase team. Never replied but maybe you could loop 'em back in here:

Thanks @Tobbe.

I signed up and created a database – and since it is Postgres, no surprise Prisma can connect.

I like the UI for the Postgres permissions.

Having to do that manually via queries can be daunting for the first time.

And so is keeping track of all the PG extensions (I know I often add fuzzy search and some text search extensions for TSV). And to see those available and those installed/on is rather nice.

Will have to look into the Auth as well as the Websockets portion of this soon.

I’d love if a change to a database table could fire off a webhook to either a RW api side graphql mutation or a function api endpoint.

Can it do that?

Yeah, of course. But it’s really nice that they’re basically giving you a free Postgresql database to use for whatever :slight_smile:

Haven’t played with it that much yet, so I don’t know :confused:

Thanks :slight_smile:

Absolutely. I’m subscribed to that thread for any updates. But the OP hasn’t been here since end of May, and supabase themselves don’t seem to have any kind of online community, so difficult to get a hold of. But I saw that DT replied in that thread. Hopefully they’ll get a notification and come back :slight_smile:

1 Like

Hi all, Supabase CEO here. Thanks for trying out Supabase - we’re still in alpha so it’s amazing to discover the community support so early.

Did you see this topic from May? Seems like the OP is from the Supabase team.

That user isn’t in the team, just a very early fan! There’s a bit to cover in both threads - I’ll keep it high level and feel free to ask for more detail

This is already built in our Realtime server, but we are yet to expose it in the UI. We also need to add some configuration routes to our middleware to make it easier to manage. If it is a necessary feature for Redwood, we could move it up the timeline

Supabase launched auth support a while ago

Only 1.5 weeks ago, and we’re still shipping :). This month we’ll release OAuth providers and email templates

(From the other thread):

I also wonder if somehow the subscription could re-render a RW Cell – if currently on a viewed page. Even just retrigger a re-fetch? Well, maybe only if the cell is showing the data that has changed.

I’m not too familiar with Redwood. If there a concept of a global store, like Redux or MobX, then it could be achieved by normalizing your initial data, then listening to the individual entities (supabase.from('users:id.eq.99').on('UPDATE').subscribe()). This gets tricky when there is a lot of data, so in the long-run we will build this into our JS library directly (with offline support). The other alternative is to listen to all database changes ( (supabase.from('*').on('*').subscribe()), but that doesn’t scale too well. Also see my next point on realtime auth -

(From the other thread):

And if the API is deployed to Netlify Functions, will Supabase Subscriptions be compatible?

You wouldn’t want to add subscriptions in a serverless function - it’s a socket connection, so you’d add it to the client. I want to call out explicitly, that we have completed security for client-side REST (using Postgres Row Level Security), but we are still working on “per-user” security for the realtime server (one of the things preventing us from moving out of alpha). Until then, you can still listen to database changes, but we recommend turning off realtime (disabling replication) for tables which you don’t want exposed to the client. We will make this simple in the UI soon.

@Tobbe, let me know if you’d like to add your example to the supabase examples folder! We’d love to work with the Redwood community to make it easier to get started with Postgres :elephant:


@kiwicopple thanks for dropping in and offering some guidance. And hats off to you and the team for the great work on Supabase!

Redwood is early as well (5 months in), so any/all collaboration + coordination is very welcome :rocket: I’m sure David T. and Tobbe will be following up soon with more discussion and questions.


Sounds like we started at the same time :ship:

I’ll set aside some time towards the end of this week to build something with Redwood to investigate if I can make a meaningful contribution back to the framework. I can see some good potential around the auth generators.

1 Like

Wow, thanks for getting back to us :slight_smile:

Being free sure helps with luring people in (at least me) :wink:

Thanks for the offer! I’d like to clean it up and make it more in line with the Redwood way of doing things first. I’ll send a PR your way when I’m ready, deal?

That’s what I was thinking too! I wanted to get to know the auth generators a bit better myself, and figured building one would be a good way of doing so. But then I decided it would probably be better to first do these two experiments to see what’s already possible with RW+supabase.

Using supabase would be more of a DIY approach than other providers. One would have to handle signup (super easy with your js lib, but still…), email verification, password reset/recovery, 2fa, rate limiting login attempts, password change, etc. I’m excited about your email template support and oauth stuff.

Deal :slight_smile:

I’m sure we can make it easy, since it is just GoTrue underneath. We already have developers requesting 2fa so once we get an opportunity to build it we will contribute back to GoTrue, so it’s a win for everyone.


Very excited for this collaboration \o/ I’ve opened an issue to track the example creation:


That’s great! I did read through (most) of the GitHib Issue and begant to understand the idea of connectors and generators … but when I saw:

    type: "webhook",
    event: "*", // all events
    relation: "*", // all changes
    config: {
      endpoint: "",
    type: "webhook",
    event: "INSERT",
    relation: "public", // only the public schema
    config: {
      endpoint: "",
    type: "webhook",
    event: "UPDATE",
    relation: "", // specific row
    config: {
      endpoint: "",

I was – yes! OK that is what I think I want :grin:

Question: would you sign the payload in some way maybe with a secret and JWS? That way can verfiy that the hook is from a trusted source?

Redwood does have a Auth Client and Provider for GoTrue. I wouldn’t mind giving that a try.

Setting up users and the roles in Supabase would be nice and would give many people the username and password - type access they have wanted (instead of Netlify or Auth0 or but via GoTrue and will have same JWT support – since some of these services are not available in all countries (has been feedback).

Not yet, but we’d be happy to add that functionality. Seems like something that everyone will want. I’d need to do some investigation into prior art - do you know what security strategies other webhook solutions use? Are they hashing the whole payload? We can shift it over to a github issue if you prefer, unless you feel it’s valuable to the Redwood community to keep the webhook discussion here

Agreed, it’s frustrating using third-party user-management especially for local development. We still have some work to do on our local-dev experience (updating the docker image now), but that’s a key focus for us now.

1 Like

I’m really eager to use Supabase as my auth provider so I started a PR here:


@Tobbe this is really impressive. I do have a question though - what do you get with Supabase on top of postgres when you use it with RW? I’m not trying to discourage you, I think this is awesome, just curious if there’s something there for me to use.

I can see @amorriscode’s PR that uses the auth aspect, anything else?

I am in Auth code this morning (adding signup() to useAuth() so can go to a direct signup tab on the Auth0 and Netlify Widget) and have updated the auth-playground a little.

I think since I am in there I will give supabase auth a try (using @amorriscode provider) because I want to see how roles return.

Redwood and @kiwicopple just wanted to let people know that v17 supports the Supabase AuthProvider as a client and the next release will include the ability to signup as well as login.

Signup will also work with Auth0 and Netlify’s UI’s to default there.

There is an open issue to write up a Cookbook for RedwoodJS + Supabase here:

You can also try out the auth here in the Playground: or see the repo at:


This is awesome, thanks everyone. I can add another item to our Hacktoberfest issue to support the Cookbook.

One small heads-up, we have some API additions/improvements coming - instead of coding our Auth functions into supabase-js, we are creating a separate gotrue-js library and then bundling it into supabase-js. This is more aligned to our philosophy of supporting existing OSS tools. I’ll drop a note here when we have the new spec

@Tobbe @dthyresson do you know if a User table can be added to Supabase and thus that User table is used by Supabase’s GoTrue implementation?

That way we are using JWT under the hood, with all the best practices of the identity management library, but the identity is stored in the application database.

So I have been using Supabase for a PG database and its auth.

The “app” tables (ie, those defined by the app’s Prisma schema) are “tables” while the users is stored up in Supabase in its “auth” area.



Note: There is no User table here … instead it is:

User Auth

So as I understand

User table is used by Supabase’s GoTrue implementation

Yes. It keeps the users, the auth, the JWT, the token refresh etc and you use the supabase-js client to auth (login, logout, get current user profile) and then using a private secret can manage users (add, edit, etc) on the api side.

Oh - and email templates, too. Something you don’t have to implement.

And RW supports all that auth - I’ve used it, one just has to implement the login/signup widgets (and we need to upgrade to Supabase 1.0)

Works great.

Not sure yet how to assign roles, but would be awesome if can set in Supabase … though now that I think about it, maybe I can just user the management api and set a

app_metadata: { roles: ['admin']} }

and that could work.

@kiwicopple ^^ is that how one might set roles on a user account in Supabase? Or should those somehow be aligned with the table permissions?