Where Supabase fits — and where teams hit the wall
Where Supabase fits well: teams who think in SQL and want a real Postgres with auth, storage, and realtime subscriptions out of the box, on an open-source core they can self-host.
Where teams outgrow Supabase: when the centre of gravity moves from the database to the work around it — background processing, inference, and flows with human steps — and that work lives outside the system reviewers look at.
A database with a platform around it
Supabase is honest about its centre: Postgres is the product, and auth, storage, realtime, and Edge Functions are arranged around it. For a data-shaped application that is a strength — SQL, joins, and constraints are things KERNSTACK tables deliberately do not offer.
The strain shows at the edges of the data model. Work that runs for minutes, steps that wait for a person, and agents that change the system itself are not database concepts, so they get bolted on beside the project rather than declared inside it.
A project graph instead — with the trade stated plainly
KERNSTACK tables are key-value tables: fast keyed access, no joins, no ad-hoc SQL. If your product lives in relational queries, Postgres is the right tool and this comparison should end there. If access is mostly keyed reads and writes, the rest of the project gets simpler:
- Search and vector indexes are declared over tables and buckets, not bolted onto the database
- Workers run long processes; workflows order function, worker, and human steps
- Agents work against the whole project graph in a sandbox, not against a connection string
Side-by-Side: Supabase vs 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
No. KERNSTACK tables are key-value stores, and there is no SQL layer hiding underneath. Teams whose product depends on joins, transactions across tables, or ad-hoc queries should keep Postgres — Supabase included. KERNSTACK fits keyed access patterns where the rest of the platform matters more.
Files move from Supabase Storage into buckets with ordinary transfers, and records export from Postgres as JSON or CSV into tables, keyed the way your application actually reads them. Nothing is imported automatically; the export is a step your team runs and can verify row by row.
Open source answers who can run the code; it does not answer where your production system runs or who operates it. The KERNSTACK difference is the operating model: one declared project, on our European bare metal, with workflows and agents as resources — not a database with a platform arranged around it.
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.