PocketBase vs Supabase
PocketBase and Supabase solve the same problem — a ready-made backend with database, auth, realtime, and file storage — with very different architectures. Supabase is a suite of services built around PostgreSQL; PocketBase is a single lightweight binary built around SQLite. This page compares them honestly so you can pick the right tool, and shows where PocketBase Cloud fits in.
Summary
| PocketBase | Supabase | |
|---|---|---|
| Database | SQLite | PostgreSQL |
| Architecture | Single binary | Suite of services (Postgres, GoTrue, PostgREST, Realtime, …) |
| Auth | Email/password, OAuth2, OTP | Email/password, OAuth2, magic links, SAML |
| Permissions | API rules (filter expressions) | Row Level Security (SQL policies) |
| Realtime | Server-Sent Events | WebSockets (Postgres replication) |
| Server-side logic | JavaScript hooks (embedded JSVM) | Edge Functions (Deno), DB functions, triggers |
| File storage | Built-in — local disk or S3 | Built-in, S3-backed |
| Resource footprint | ~15 MB binary, runs on the smallest VPS | Multiple services; heavier baseline |
| Self-hosting | Trivial — one file | Possible, but complex (Docker Compose stack) |
| Managed hosting | PocketBase Cloud | supabase.com |
Database: SQLite vs PostgreSQL
This is the fundamental difference.
PocketBase uses SQLite — the database is a single file living next to the process. There’s no network hop between app and database, which makes reads extremely fast; a modest server handles thousands of requests per second. Backups are as simple as copying a folder. The trade-offs: writes are serialized (one writer at a time), and you scale vertically by getting a bigger server rather than horizontally.
Supabase uses PostgreSQL — a full client-server database with everything that comes with it: complex joins and window functions, high concurrent write throughput, and the extension ecosystem (PostGIS for geospatial, pgvector for embeddings, and hundreds more). The trade-off is operational weight: connection pooling, network latency between services, and more knobs to tune.
For most CRUD applications — SaaS dashboards, mobile app backends, content sites — SQLite’s write serialization is never the bottleneck. If your workload is genuinely write-heavy at high concurrency, or depends on Postgres extensions, Supabase is the better fit.
Permissions: API rules vs Row Level Security
Both lock down data per user, with different mental models.
PocketBase API rules are short filter expressions attached to each collection operation:
@request.auth.id != "" && owner = @request.auth.id
They’re readable at a glance and live in the admin UI next to the schema.
Supabase RLS policies are SQL statements on each table:
create policy "owner can read" on posts
for select using (auth.uid() = owner);
RLS is more powerful (full SQL is available) but easier to get wrong — a table without policies enabled is exposed through the auto-generated API, and debugging policy interactions across tables takes real SQL fluency.
Realtime
PocketBase streams record changes over Server-Sent Events. Subscriptions respect your API rules automatically, and SSE works through ordinary HTTPS proxies with no special infrastructure. It scales further than its lightweight design suggests: a single instance on 2 CPU cores and 4 GB RAM comfortably handles 1,000+ concurrent realtime connections.
Supabase streams over WebSockets fed by Postgres logical replication, and adds presence and broadcast channels — useful for cursors-on-screen collaborative features. If you need presence, Supabase has it built in; with PocketBase you’d implement it yourself.
Server-side logic
PocketBase embeds a JavaScript VM: hooks add custom routes, react to record changes, and run cron jobs — deployed next to your data with zero extra latency. They’re PocketBase’s equivalent of Supabase’s functions, and on PocketBase Cloud they’re included on every plan with no invocation billing. For bigger workloads, PocketBase Cloud lets you deploy a full backend (Node.js, Deno, Bun, Next.js) alongside your instance — something Supabase doesn’t offer at all.
Supabase offers Edge Functions (Deno, deployed to edge locations), database functions, and triggers. Edge Functions scale to zero and run close to users, but run far from your database, so data-heavy functions pay round-trip latency.
Operational simplicity
PocketBase’s single-binary design means there’s one process to run, one folder to back up, and one log to read. Supabase self-hosted is a multi-container stack (Postgres, GoTrue, PostgREST, Realtime, Storage, Kong), which is why most teams use its managed platform.
The same logic applies to PocketBase: it’s easy to self-host, but someone still has to provision the server, configure HTTPS, set up backups, and monitor it. That’s what PocketBase Cloud does — a managed instance with automatic HTTPS, backups, monitoring, and log streaming, provisioned in under a minute, with a free plan to start.
When to choose which
Choose PocketBase (and PocketBase Cloud) when:
- You want one simple system you can fully understand
- Your app is read-heavy CRUD — which is most apps
- You value fast local development (run the exact same binary locally)
- You want predictable costs on small-to-medium workloads
Choose Supabase when:
- You need full PostgreSQL — complex SQL, PostGIS, pgvector
- Your workload has high concurrent write throughput
- Your team already lives in the Postgres ecosystem
- You need built-in presence/broadcast channels or SAML SSO