What moving off a Postgres centre looks like
The data move is the easy part to describe and the part to do carefully: export each table, decide which keyed access patterns replace your queries, and load the result into KERNSTACK tables. Queries that were joins become either a second keyed read or a reason to keep that dataset on Postgres a while longer.
Files follow the same path into buckets, and the Edge Functions become functions or workers depending on how long they run. Nothing is imported automatically — the re-declaration is the work, and it is also what leaves the new system fully described in stack.json.
The honest case for staying
If your team thinks in SQL, your queries are genuinely relational, and your background work is small, Supabase is a good home and moving buys little. The case for KERNSTACK starts when the workflow, agent, and review story matters more than the query language — and when one European zone under one operator is a requirement, not a preference.
See also our detailed KERNSTACK vs Supabase comparison and the Software Lifecycle Cloud architecture pillar.
Why teams switch from Supabase to KERNSTACK
| Dimension | Supabase | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Centre of the system | A Postgres database with services around it | The project graph declared in stack.json |
| Data model | Relational tables, SQL, joins, constraints | Key-value tables with keyed access — no SQL |
| Background work | Edge Functions and database queues at the edges | Container workers and workflows as first-class resources |
| Search | Postgres full-text and pgvector inside the database | Text and vector indexes declared over tables and buckets |
| Operator | Supabase Cloud on hyperscaler regions, or self-hosted | Our own bare metal in Europe, one zone per project |
| Bill | Platform tiers plus compute and egress lines | One credit balance across the whole project |
Frequently asked questions
Yes. Nothing requires the whole product to move. Keep a relational dataset where it is, run the surrounding compute, files, and workflows on KERNSTACK, and call across the network — teams do this while they learn which access patterns are actually keyed.
With the export tools you already have: SQL dumps or CSV and JSON exports per table, reshaped to the key your tables declare, then loaded in. It is deliberately boring — the interesting decision is the key design, not the transfer.
SQL, realtime subscriptions, and a mature auth product — stated plainly. What you gain is the rest of the platform as declared resources: workers, workflows with human steps, search indexes, and agents operating on the same project graph.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.