Comparison
Warpkit vs Supabase
Supabase is a managed platform: Postgres, auth, storage, and realtime behind one dashboard, with a public anon key and row-level security policies gating access to shared tables.Warpkit isolates tenants by giving each user their own SQLite file, there's no shared table to write a policy for, and no policy to forget.
Worth being upfront: our own Postgres/serverless fork (included in the same purchase) makes the same isolation-by-policy tradeoff described below, application-level scoping instead of a per-user file. If shared Postgres is what you actually need, whether from Supabase or from that fork, the isolation guarantee below doesn't come free anymore, you're back to writing and reviewing scoping logic carefully. That's the real tradeoff, not a Supabase-specific flaw.
| Warpkit | Supabase | |
|---|---|---|
| Price | $199 one-time, lifetime access | Free tier, then usage-based |
| Tenant isolation | Per-user SQLite file | Shared Postgres + row-level security |
| Isolation model | Isolation by construction | Isolation by policy (RLS you write and maintain) |
| Auth | better-auth | Supabase Auth |
| Two-factor auth (authenticator app codes) | ||
| Public API key model | None, server functions only | Public anon key, ships in your JS bundle |
| Managed hosting available | ||
| Realtime | ||
| Built-in file storage | ||
| Background jobs | ||
| Serverless deploy |
The failure mode that matters
Supabase's row-level security is off by default per table, and the anon key is meant to be public, it ends up in your client bundle. Miss enabling RLS on one user-data table and anyone holding the anon key can read every row across every tenant. Worse: a table with RLS turned on but a policy of USING (true) shows as enabled in the dashboard while providing no real restriction. Both failure modes are invisible until data leaks. Warpkit's per-user SQLite has no equivalent: isolation comes from the filesystem, not from a policy someone has to remember to write correctly.
Choose Warpkit if…
- You want tenant isolation nobody can forget to configure
- You want auth as code (better-auth) instead of a managed auth service
- You never want a public API key sitting in your client bundle
- You want a built-in job queue with retries and dead-letter handling (jobs that keep failing get set aside for review, not retried forever)
- Self-hosting on your own infra matters more than a managed dashboard
Choose Supabase if…
- You need realtime collaboration features
- You want managed hosting with zero infrastructure to run
- You need cross-tenant SQL/BI queries over one shared database
- You want serverless deploy on Vercel or similar
- Your team is already fluent in RLS and reviews policies carefully