Skip to content

Supabase data source


The video above was recorded before the latest WeWeb UI update but the logic remains the same. If you're unsure where to find something in the new interface of the WeWeb editor, you can see what changed here.

Plugin configuration

The Supabase data source plugin allows you to access the tables in the public schema of your Supabase project.

To add the plugin in WeWeb, go to Plugins > Data sources:

Supabase data source plugin

Once you've added it, you will be invited to share your Supabase Project URL and Public API key. In Supabase, you can find both in the Settings > API menu:

Supabase project settings

Realtime tables

Once you have conntect WeWeb to your Supabase project, you'll be able to tell WeWeb which tables are realtime in Supabase:

Enabling realtime tables


Enabling the realtime option in WeWeb will not activate realtime in Supabase. You need to make sure realtime is activated in Supabase.

Realtime is disabled by default in Supabase for better database performance and security. Learn more about realtime functionalities in their documentation.

Get data from Supabase

Once you've added the Supabase data source plugin, you'll be able to create a collection to get data in WeWeb.

You can do this:

  • by clicking on Add a Collection when you add the plugin, or
  • by going to Data> New and choosing Supabase as the Source

Supabase collection

You will then be able to select the Table from which you want to pull data. By default, you'll be in Guided mode and get all the data from all the fields.

In the example below, we decided to exclude the data from the created_at field in our vehicles table:

Select fields to fetch

As a result, WeWeb does not fetch the created_at field. This is helpful because we can exclude data that we don't want to load in the frontend, either because we don't need it or because it's confidential.


If you have enabled Row-Level Security in Supabase, make sure you have also added a Policy that allows users to read the data in the table. Otherwise, WeWeb won't be able to get the data.

Advanced mode

In our database, we have 2 separate tables for vehicles and locations.

In the vehicles table, we made a reference to the locations table in our location_id field so we know where each car is:

Reference field in Supabase

The problem is, if we only ask for the data from the location_id field of the vehicles table, Supabase will only return the id, not the name of the location:

Reference field value

If you choose the Advanced mode, you will be able to get the name field of the location instead of the id by making custom queries to Supabase:

Custom Supabase query in WeWeb

In the example above, we are telling Supabase:

  • send me the data in the id, model, and mileage fields of the table selected (in this case vehicles)
  • in the locations table, look for the location_id from the table selected (in this case vehicles) and send me the data in the name field


The Advanced mode can be very powerful and save you a lot of time. However, it also means fetching more data, including data you might already have fetched in another collection.

In programming, it's usually best to avoid duplicate information and redundant API calls.

If we planned to have a locations collection with the names of locations, instead of fetching the same information twice in WeWeb, it would be best practice to fetch only the location_id from the vehicles table and use a lookup formula in WeWeb to find the name of the location in the locations table.

Update a record

When you add the Supabase data source plugin, it unlocks all the CRUD actions available in Supabase in WeWeb's workflows:

  • Select
  • Insert
  • Update
  • Upsert
  • Delete

In the example below, we are using the Update row workflow that comes by default with WeWeb's data grid element and added a Supabase Update action:

Supabase update action in a WeWeb workflow

In our Update action, we:

  1. selected the vehicles table, and
  2. mapped the id of the record we want to update in Supabase to the id of the record we edited in the data grid:

Configure Supabase update API call

Then we bound the mileage field in our Supabase table to the data grid event to send the value in the mileage column of our data grid:

Binding mileage value

And that's it!

If you switch to Preview mode, you will be update your Supabase table from your WeWeb Data Grid:

Datagrid Supabase update


The way we mapped the values of the record to the Supabase fields we want to update is very specific to the Update row workflow of the data grid element but you get the idea: you need to tell Supabase what record it should update and where it can find the new values.

In the case of the data grid element, this information can be found in the Event of the Update row workflow. If users are updating a record via a form submissions, the information will be in the input fields of the form container.

Securing data

By default, all the data in the tables that are in the public schema of your Supabase project can be read, updated, or deleted.

Supabase allows you to enable Row-Level Security for each of your tables:

Enable Supabase RLS

If you want to restrict certain actions to specific users or roles, you'll need to:

Supabase provides a number of policy templates to get you started:

Supabase policies

In the example below, we say that users can:

  1. update a record
  2. in the "locations" table of the "public" schema
  3. if they are authenticated

Supabase policy example


Once you enable RLS on a Supabase table, you won't be able to access the data in a WeWeb Collection unless you've added a policy.

Enable Supabase RLS


Row Level Security & Policies

More often than not, when you're unable to fetch data from Supabase or update records in Supabase through WeWeb workflow, the issue can be fixed by looking at the security and policies related to the table you're trying to interact with.

For example, if you have enabled Row-Level Security (RLS) on a Supabase table, you won't be able to access the data in a WeWeb Collection unless you've added a policy saying everyone can read data in that table.

If you have added a policity that requires users to be authenticated and have a specific role to access or edit data, you'll need to log into your WeWeb app in preview mode as a user with that specific role before you can get or edit that data. Otherwise, the API calls will return an Unauthorized or Access denied error.