Guides

Migrating from Supabase

Berth follows many of the same ideas as Supabase: Postgres per project, PostgREST style filters, a publishable key plus user JWT, row level security. There is no client SDK, so each supabase-js call becomes one fetch. This page maps them, and lists what Berth does not do.

Client setup

A ten line helper covers most of what the client did:

const BASE = "https://api.atberth.com/v1/apps/notes_app";
const KEY = "bpk_...";
let session = null; // { access_token, refresh_token, user }
async function berth(path, { method = "GET", body, query } = {}) {
  const url = new URL(BASE + path);
  if (query) for (const [k, v] of Object.entries(query)) url.searchParams.append(k, v);
  const headers = { apikey: KEY, "Content-Type": "application/json" };
  if (session) headers.Authorization = `Bearer ${session.access_token}`;
  const res = await fetch(url, { method, headers, body: body && JSON.stringify(body) });
  const data = res.status === 204 ? null : await res.json();
  if (!res.ok) throw Object.assign(new Error(data.message), { code: data.error });
  return data;
}

Table queries

Side by side:

// Supabase
const { data } = await supabase.from("notes")
  .select("id,title").eq("done", false).order("created_at", { ascending: false }).range(0, 9);
// Berth
const { rows } = await berth("/tables/notes/rows", {
  query: { select: "id,title", done: "eq.false", order: "created_at.desc", limit: 10 },
});

The same query from a shell:

berth tables create --app "$APP" notes title:text:notnull done:boolean
curl -sS -X POST https://api.atberth.com/v1/apps/$APP/tables/notes/rows \
  -H "Authorization: Bearer $SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '[{"title":"Buy milk","done":false},{"title":"Call the bank","done":true}]' > /dev/null
curl -sS -G https://api.atberth.com/v1/apps/$APP/tables/notes/rows \
  -H "Authorization: Bearer $SECRET_KEY" \
  --data-urlencode "select=id,title" \
  --data-urlencode "done=eq.false" \
  --data-urlencode "order=created_at.desc" \
  --data-urlencode "limit=10"

Auth

// Supabase
await supabase.auth.signInWithPassword({ email, password });
// Berth
session = await berth("/auth/login", { method: "POST", body: { email, password } });

curl -sS -X POST https://api.atberth.com/v1/apps/$APP/auth/signup \
  -H "apikey: $PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"ada@example.com","password":"correct horse battery"}' | jq .user.email

Users do not move over with their Supabase passwords. Create them with POST /auth/users and let them sign in with an email code, then set a password.

Row level security

The usual Supabase policy using (auth.uid() = user_id) is the Berth owner policy. Berth adds owner_id for you and turns on RLS. Rename your user_id column to owner_id, or copy it across, when you move data.

berth tables policy --app "$APP" notes --read owner --write owner

The API manages four policy levels. For rules beyond them (roles, team membership), put the logic in a function that uses the secret key.

Storage

Supabase storage policies on (storage.foldername(name))[1] = auth.uid() map to an owner bucket, which requires keys to start with the user id.

Edge functions

supabase.functions.invoke("hello", { body }) becomes POST /functions/hello. Both run Deno, and Deno.serve code carries over. Set secrets with berth env set instead of supabase secrets set, and read the injected BERTH_SECRET_KEY instead of SUPABASE_SERVICE_ROLE_KEY. npm:, jsr:, and https:// imports work as they do on Supabase. A function is one file, so there is no shared _shared folder: bundle local imports into the file first.

Scheduled jobs

On Supabase a scheduled job is usually pg_cron plus pg_net calling an edge function over HTTP with the service role key. On Berth the schedule belongs to the function itself, and no key travels in SQL:

cat > nightly.ts <<'EOF'
export default async (req: Request) => {
  if (req.headers.get("Berth-Key-Type") !== "schedule") return new Response(null, { status: 403 });
  const { scheduled_at } = await req.json();
  return Response.json({ ran_for: scheduled_at });
};
EOF
berth functions deploy --app "$APP" nightly nightly.ts --schedule "0 3 * * *" --json | jq -e '.function.schedule == "0 3 * * *"'
berth functions deploy --app "$APP" nightly nightly.ts --no-schedule

Schedules are in UTC and fire at most once a minute. Details are on Functions.

Realtime

A channel().on("postgres_changes", { event: "*", table: "notes" }) subscription becomes an EventSource on /tables/notes/stream, with insert, update, and delete events. See Realtime.

Database webhooks

Supabase database webhooks map to Berth webhooks: pick a table and events, and Berth POSTs signed JSON with record and old_record, with retries.

Moving the data

supabase db dump has a Berth counterpart in berth apps export, which writes a pg_dump file. To bring data in from Supabase, export each table as CSV and load it with berth import, or insert in batches of 1,000 rows. Create the tables with berth tables create first so they get Berth's ids, timestamps, and policies.

printf 'title,done\nImported from Supabase,false\n' > notes.csv
berth import --app "$APP" notes notes.csv
berth apps export "$APP" -o notes_app.dump

What Berth does not have

• No embedded joins. select("*, profiles(*)") has no equivalent. Make two requests, or join in SQL or a view from your server.
• No OAuth or social login. Email and password, and email codes, only.
• No or= filters. Filters are ANDed. Use in.(...) or SQL.
• No phone or SMS auth.
• No presence or broadcast channels. Realtime is row changes only.
• No client SDK. Plain HTTPS and the CLI.
• No custom policy expressions in the API. The four policy levels, plus functions for anything else.