Migrate from Supabase to KERNSTACK

The one decision everything else depends on: your queries

KERNSTACK tables are key-value tables. There is no SQL, no joins, and no query planner underneath. So the first migration task is reading your Postgres schema as access patterns: which queries fetch by primary key or a known secondary key, and which genuinely join, aggregate, or filter ad hoc? The first group moves cleanly — each becomes a keyed read. The second group is a decision: denormalise into the key shape, answer it with a declared text or vector search index, or keep that dataset on Postgres and call it over the network.

Teams that skip this reading exercise and try to copy table shapes one-to-one end up with keys nobody queries by. Teams that do it usually find most product data is keyed already — users by id, orders by user and date, documents by owner — and the relational remainder is smaller than feared.

• Supabase Auth users are the sensitive piece: password hashes do not export. Plan a re-login or password-reset flow at cutover.
• Row Level Security policies do not translate. Access rules are enforced in your functions and workers, in code your reviewers read.
• Realtime subscriptions have no direct equivalent. If live updates are core to the product, weigh that before moving the datasets behind them.

What moves, in dependency order

Files first, because they are risk-free: Storage objects copy into buckets over HTTPS and nothing about the database changes. Data second: export each Postgres table with pg_dump or CSV export, reshape rows to the declared keys, load, and verify counts and spot-check records against Supabase. Code third: Edge Functions are TypeScript, and TypeScript becomes container workers with the nodejs runtime — expect small adjustments where Deno-specific APIs were used.

Cut users over last, alongside the account plan. The old Supabase project keeps running through the whole sequence, so every step can be checked against production behaviour before anyone depends on it.