-
Notifications
You must be signed in to change notification settings - Fork 135
Description
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
pgclient instead of aSupabaseClient - 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