Multiple Supabase Databases

As far as I know we can just install the supabase plugin once. But what if I need to have access to multiple Supabase Databases/Projects?

Is then the way with the plugin over and I have to use Postgresql?

@erbteilung do you store user data in one supabase project, and everything else in a separate supabase proj?

Or does User Data (data specific to an individual user) live across both?

You can either

  1. use WeWeb’s SQL plugin to connect to your supabase PostgreSQL instance directly

    • do use Supavisor for pooling (port 6543)
    • do not use the default postgres user over 5432. See Supavisor docs
  2. use WeWeb’s REST API plugin to connect your Supabase API(s).

I would use the native WeWeb<->Supabase plugin for the supabase project that contains most of your User Data

I strongly advise against option number one, the rest API is safer. As an alternative instead of using the built-in supabase integration you can create your own using supabase sdk either in a custom code plugin or with js actions in workflows.

1 Like

This. You should even be able to do different schemas too.

Thank you very much. Now it is clear not to use the sql way…
Now I just have to figure out how I can create my own supabase sdk in a custom code plugin like you mentioned. What is the right approach? Also not to overwrite some stuff of the “internal” supabase plugin. If it is only a few lines of code maybe you could share your knowledge?

It would be amazing…

Maybe you can create edge functions in your main project, sending request and returning data from your second project ?

I will note it could be interesting to expose the whole SDK so you can use it to create multiple client.

Yeah, I second this, it would require a little of work, but you wouldn’t even need edge functions probably, you might be able to do this even with stored procedures and APIs of PostgREST instances.

If it was few line of code Alexis would have finished the new version of the Supabase plugin in a blink :upside_down_face:

If you want to build your own integration it’s better if you play a bit with the Supabase sdk and understand how to use it. You can play with it simply using js actions in workflows and following the basic supabase tutorials in their docs.

I chose WeWeb because one doesn’t necessarily have to code. I’ve already discovered that it doesn’t always work without JavaScript, but it was relatively manageable. In this case, however, you probably have to be a JavaScript expert. Maybe a brief overview of my use case would be helpful: Currently we have a Supabase multi-tenancy database, so all tenant data is in the same database (schema). In the medium term, however, we would like to offer separate databases per customer or even the option for customers to host the database on their own server. If I’m not mistaken, I suggested a few months ago to control the Supabase plugin with a variable. So I only have one plugin, but I can use it to connect different databases. However, the connection and login data would then have to be read from another database, for example Xano. In any case, I don’t see a way to use multiple Supabase databases at the moment. And whether this even works with the SDK has not yet been proven. Have you perhaps already thought about my suggestion?

I remember @Alexis mentioned there was an update that would allow us to fork the Supabase plugin, but I’m not sure when it is coming.

I thought about it a little bit,

We initialize plugins before an user is logged in (because we need auth plugins to work to fetch and restore the connected user for exemple). But here you need the supabase sdk to be initialised after the user was logged in, so you want to make it login to a third party first. But you will probably have a hard time making the third party be the authentication provider for supabase then (Having a Xano token will not magically make you able to access your supabase resources, except if every supabase request is proxied by xano).
And as we cannot allow binding in the plugin settings easily so you will not be able to make it dynamically dependent of the user. Another issue is you cannot have multiple auth system in the same time so no Supabase Auth and Xano Auth.

But I’ve an idea,

I think the easiest flow would be to have

  1. A login screen where you enter the user email first
  2. A special endpoint (in xano or supabase or somewhere else) you can send the user email and it will return the supabase instance url and public key related to this user
  3. We should provide a new action allowing you to reconnect the supabase instance with the settings you received
  4. Once reconnected to the specific user instance, the user can finish his signin process by entering his password and it will execute the sign in action normally

It works only if the schema is exactly the same across all the instances of course.

@Broberto We are working on it right now. The idea is still to allow everyone to develop plugins (auth, datasource, extension), I don’t have any estimation to communicate as I don’t know if we will release it as soon as it’s ready

Thank you for this useful answer! Your suggestions seems to be the solution. I will now patiently wait for the implementation.

Actually, two lines of javascript should already do the trick

await wwLib.wwPlugins.supabaseAuth.load(<instance-url>, <public-api-key>)
wwLib.wwPlugins.supabase.syncInstance()

But if you’re protecting page through our native feature (set page has private with or without roles) it will not work before we achieve our transition and remove our weweb-server (because he we still try to use the instance url and public api key you provided as plugin settings to check the user roles and give access to the page, it cannot be made dynamic)
In the coming weeks/months, the code above should be enough to make your usecase works