Adapters — Supabase (Postgres over HTTP)

Use the Supabase adapter when your data lives in Postgres and you need RLS/auth, SQL reliability, and a managed cloud. You keep the same vibecode‑db client API; only the storage changes.

Execution rule: In v1.0, .select(projection) executes the query — chain filters/modifiers before calling it. Writes (insert, update, delete) execute immediately.

When to use

• Production apps that need Postgres, RLS policies, and auth.
• Teams who want a cloud‑hosted source of truth with SQL tooling.
• Projects that may start local (SQLite) and later move to the cloud without UI rewrites.

Minimal wiring

1// db/client.supabase.ts
2import { createClient } from '@vibecode-db/client'
3import { SupabaseAdapter } from '@vibecode-db/client/adapters/supabase'
4import { db } from './schema' // your defineSchema(...)
5
6export const vibecode = createClient({
7  dbSpec: {
8    schema: db.zodBundle,
9    relations: db.relations,    // enables typed, relation-aware projections
10    // seed?: { ... }            // optional boot data (policy-dependent)
11    // meta?: { ... }            // optional adapter-specific metadata
12  },
13  adapter: (ctx) => new SupabaseAdapter(ctx, {
14    url: process.env.NEXT_PUBLIC_SUPABASE_URL!,
15    key: process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, // public/anon for browser
16  }),
17})

The Supabase adapter is bundled in @vibecode-db/client (no extra package to install).

Adapter options (at a glance)

Example: first query (with relations)

Supabase/PostgREST can support richer expansions, but to keep your code portable across adapters, use one‑level many‑to‑one projections (works everywhere we support today).

1const posts = await vibecode
2  .from('posts')
3  .eq('published', true)
4  .order('created_at', { ascending: false })
5  .limit(10)
6  .select('id, title, users(name)') // many-to-one: posts → users

RLS & auth

• Ensure your Row Level Security policies permit the intended reads/writes.
• The adapter sends operations over HTTP; errors will surface from PostgREST/RLS if rules block the action.
• Keep secrets on the server when possible; use the service key only in trusted environments.

Migrations, seeding & portability

• Manage Postgres DDL (tables, indexes, FKs) in your preferred migration tool.
• Optional dbSpec.seed can be applied via a one‑time bootstrap script; avoid seeding on every client launch.
• Keep projections portable if you plan to swap between SQLite and Supabase (prefer one‑level M→1 expansions).

Summary

Choose Supabase when you need managed Postgres with RLS/auth and want to keep the same vibecode‑db query surface you use locally. Start local, go cloud — your schema and queries stay the same, only the adapter changes.