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