Skip to content

Add Supabase State Adapter #252

@vincenzodomina

Description

@vincenzodomina

Problem Statement

I’d like Chat SDK to support a Supabase-native production state adapter:

import { createSupabaseState } from "@chat-adapter/state-supabase";

I know Supabase is Postgres under the hood, and @chat-adapter/state-pg is already close in terms of storage model. But for apps that are already fully standardized on Supabase, the current Postgres adapter does not fit the operational and architectural model well.

My app already uses Supabase as the central database and access layer. I want the Chat SDK state adapter to plug into that same setup instead of introducing a second, parallel way of talking to the same database.

What I want is:

  • reuse the existing Supabase client I already create and manage in the app
  • avoid managing separate direct Postgres URLs/credentials just for Chat SDK state
  • keep DB access centrally controlled through the same Supabase setup and conventions as the rest of the app
  • manage schema creation declaratively through Supabase migrations/schema files, not at runtime
  • control security, roles, grants, and schema exposure explicitly in Supabase
  • rely on Supabase-native APIs and best practices internally where possible
  • avoid extra infrastructure or additional cache/database systems just to satisfy Chat SDK state

This would make Chat SDK much easier to adopt for teams that already use Supabase everywhere.

It would provide:

  • better architectural consistency
  • simpler ops
  • fewer credentials and connection types to manage
  • no extra infra just for state
  • easier compliance with existing database governance and security patterns

This is not just “Postgres, but with a different brand name.” For Supabase users, client reuse, declarative schema control, permissions, and operational simplicity are core parts of the platform model. A dedicated Supabase adapter would make Chat SDK feel like a natural fit in those apps.

Proposed Solution

A good API would be:

createSupabaseState({
  client,
  schema?,
  keyPrefix?,
  logger?,
})

The ideal package would:

  • accept an existing SupabaseClient
  • ship a SQL migration/schema file that can be added to a Supabase declarative schema folder
  • support a dedicated custom schema instead of requiring public
  • let users own the schema lifecycle through their normal migrations
  • let users control grants, roles, and exposure explicitly
  • use Supabase APIs internally rather than raw pg

Alternatives Considered

@chat-adapter/state-pg comes close, but is not a good fit

@chat-adapter/state-pg solves a more generic Postgres use case, but it doesn’t map cleanly onto a Supabase-first application.

The main mismatches are:

  • it expects a direct Postgres connection or pg client instead of a SupabaseClient
  • it introduces a separate raw DB access path alongside the rest of the app
  • it requires separate Postgres connection management instead of reusing centrally controlled Supabase access
  • it creates schema objects at runtime on connect(), which conflicts with declarative schema management
  • it does not align with how Supabase apps typically handle permissions, roles, exposed schemas, and RPC boundaries
  • it misses the convenience of “just use the Supabase client I already have”

So while Supabase is powered by Postgres, the developer experience and production setup are meaningfully different.

Use Case

Something along these lines:


import { createClient } from "@/lib/supabase/server";
import { createSupabaseState } from "@chat-adapter/state-supabase";

const supabase = await createClient();

const bot = new Chat({
  userName: "mybot",
  adapters,
  state: createSupabaseState({
    client: supabase,
    schema: "chat_state",
  }),
});

Priority

None

Contribution

  • I am willing to help implement this feature

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions