createClient pattern lacks of extensibility with multi-schema usage (singleton gotrue warning)

[softmarshmallow]

I am constantly getting warning from supabase.

Multiple GoTrueClient instances detected in the same browser context. It is not an error, but this should be avoided as it may produce undefined behavior when used concurrently under the same storage key. 

I am using multiple clients with singleton: false since I am using multiple schema, and client instanciation with singleton does not allow it.

e.g.

import type { Database } from "@/database.types";
import { createBrowserClient as _createBrowserClient } from "@supabase/ssr";

const __create_browser_client = <
  SchemaName extends string & keyof Database = "public" extends keyof Database
    ? "public"
    : string & keyof Database,
>(
  schema: SchemaName
) =>
  _createBrowserClient<Database, SchemaName>(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      db: {
        schema: schema,
      },
      isSingleton: false,
    }
  );

export const createBrowserClient = () =>
  __create_browser_client<"public">("public");

export const createBrowserFormsClient = () =>
  __create_browser_client<"grida_forms">("grida_forms");

export const createBrowserCommerceClient = () =>
  __create_browser_client<"grida_commerce">("grida_commerce");

export const createBrowserCanvasClient = () =>
  __create_browser_client<"grida_canvas">("grida_canvas");

export const createBrowserWWWClient = () =>
  __create_browser_client<"grida_www">("grida_www");

export const createBrowserWestReferralClient = () =>
  __create_browser_client<"grida_west_referral">("grida_west_referral");

(this is not a @supabase/ssr problem, but a supabase-js problem)

What is the best practice when using multiple schema? do you have plans for supporting switching schema on-the-go with a singleton instance?

e.g.

// switch schema with builder pattern
const client = createClient()
client.schema("other_schema").from("...")


// or.. (multi singleton by group)

const client = createClient({singleton: true, singletone_group: "public"})
const otherClient = createClient({singleton: true, singletone_group: "other_schema"})


// core client - consumer client pattern
const base = createCoreClient()
const client = createClient(base)
const otherClient = createClient<"other_schema">(base,  {schema: "other_schema"})

[egstad]

+1

[Apoorvgarg-creator]

This is not an official response from Supabase. I was exploring the code and came across this.

Hi @softmarshmallow @egstad, That is a fascinating problem. I am not entirely sure how you can suppress the warning, but I liked your builder pattern idea for supporting switching schema on the go.

You can try this solution - You can provide a unique storageKey for each client instance. This prevents them from sharing the same localStorage/sessionStorage key, which is the root cause of the warning.

This does NOT suppress the warning but prevents token/session clashes between instances.

Link - auth-js/GoTrueClient

Link - auth-js/Warning

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 6 months. It will be closed in 30 days if no further activity occurs.

If this is still relevant, please comment to keep it open.

[softmarshmallow]

can we get some official answers from the team

[IdellHeaney]

bump

[mandarini]

Hey there! Thanks for bringing this up and providing such detailed examples. After discussion with the auth team, here's our official guidance for handling multiple schema usage:

Recommended Solution: Use Different Storage Keys

The best practice when creating multiple clients for different schemas is to provide a unique storageKey for each client instance. This ensures that auth state for each schema remains isolated and prevents the warning.

Here's how to update your code:

import type { Database } from "@/database.types";
import { createBrowserClient as _createBrowserClient } from "@supabase/ssr";

const __create_browser_client = <
  SchemaName extends string & keyof Database = "public" extends keyof Database
    ? "public"
    : string & keyof Database,
>(
  schema: SchemaName
) =>
  _createBrowserClient<Database, SchemaName>(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      db: {
        schema: schema,
      },
      auth: {
        storageKey: `sb-${schema}-auth-token`, // Add unique storage key per schema
      },
      isSingleton: false,
    }
  );

export const createBrowserClient = () =>
  __create_browser_client<"public">("public");

export const createBrowserFormsClient = () =>
  __create_browser_client<"grida_forms">("grida_forms");

export const createBrowserCommerceClient = () =>
  __create_browser_client<"grida_commerce">("grida_commerce");

export const createBrowserCanvasClient = () =>
  __create_browser_client<"grida_canvas">("grida_canvas");

export const createBrowserWWWClient = () =>
  __create_browser_client<"grida_www">("grida_www");

export const createBrowserWestReferralClient = () =>
  __create_browser_client<"grida_west_referral">("grida_west_referral");

Why This Works

As of PR #1767, the warning only appears when multiple clients share the same storage key. By providing different storage keys, each schema gets its own isolated auth storage namespace, and you won't see the warning anymore.

About Multiple Sessions

Having multiple sessions (and thus multiple access/refresh tokens) is perfectly fine unless you have "Enforce a single-session per user" enabled in your Auth settings. Check out our user sessions documentation for more details on session management.

Future Improvements

We're tracking enhancements for v3 that would provide better ergonomics for multi-schema usage, including some of the patterns you suggested like schema switching with a builder pattern. Your feedback is valuable and helps us prioritize these improvements!

Hope this helps! Let us know if you have any questions. 💚

[mandarini]

Also, I'm talking with the docs team, so that we can improve our docs around this. Thank you all.