PocketBase vs Supabase

PocketBase and Supabase both promise the same thing — auth, database, realtime, and file storage without writing the plumbing yourself — but they sit at opposite ends of the self-hosting spectrum. PocketBase is a single Go binary with an embedded SQLite database; Supabase is a full Postgres platform delivered as a multi-container Docker stack. The decision is less about features than about how much backend you actually need to run.

One binary vs a platform

PocketBase is the minimalist's answer: one Go executable with SQLite embedded, bundling auth, realtime subscriptions, file storage, and an admin dashboard with zero external dependencies. Download it, run it, and you have a backend listening on port 8090 — no orchestration, no service mesh, nothing else to keep alive. It's MIT licensed and its catalog difficulty is a 1 out of 5, the lowest rating we give.

Supabase starts from PostgreSQL and builds outward with TypeScript services. The self-hosted deployment is a multi-container Docker Compose stack — Postgres, PostgREST, an auth service, Realtime, Storage, and Kong as the API gateway — which is why it lands at a 4 out of 5 difficulty and a 4 GB RAM floor, against PocketBase's 512 MB. It's Apache-2.0 licensed, and the database is the product: you psql straight into it.

Database: SQLite vs Postgres

This is the real fork in the road. PocketBase's embedded SQLite is a genuine strength at small scale — reads are fast, there's no connection pooling to tune, and the entire database is one file on disk. Backups are almost embarrassingly simple: copy the data directory and you're done.

The trade-off is ceiling. SQLite lives inside the one PocketBase process, so scaling means a bigger machine, not more machines. Supabase's Postgres brings the whole relational toolbox — real SQL, joins, row-level security, the extension ecosystem (pgvector, PostGIS), and battle-tested replication and tooling when a project outgrows one node. If you already know your app will need heavy concurrent writes, analytical queries, or read replicas, Postgres is the answer and PocketBase never claimed otherwise.

Features & extensibility

Both cover the core BaaS surface: authentication, database, file storage, and realtime subscriptions. Supabase layers more on top — auto-generated REST and GraphQL APIs over your schema, Edge Functions, and row-level security as the default authorization model. PocketBase keeps the surface deliberately small and lets you extend it in Go or JavaScript hooks when the built-ins run out; there's no serverless-functions tier because the whole thing is already just one program you can compile things into.

The ecosystems differ the same way. Supabase inherits everything that speaks Postgres — ORMs, admin tools, migration frameworks — plus a large community of Firebase converts. PocketBase's community is smaller but its scope is smaller too; there is simply less machinery to need help with.

Self-host footprint & operations

Here PocketBase is in a different weight class. A 512 MB VPS — the cheapest tier most providers sell — runs it comfortably, and "deploying" is copying a binary and starting a process (Docker works too, if you prefer the wrapper). Upgrades are replacing one file. Backups are copying one directory.

Supabase's stack wants 4 GB of RAM before you store a single row, and day-two operations mean keeping half a dozen containers healthy, managing .env secrets for the gateway and JWT signing, and running proper Postgres backups. None of that is unreasonable — it's the price of a real platform — but it is an order of magnitude more surface than PocketBase asks you to own.

Licensing

No copyleft concerns on either side: PocketBase is MIT, Supabase is Apache-2.0. Both are safe to self-host commercially; pick on architecture, not license.

Which should you self-host?

Pick PocketBase if…

• You want the smallest possible operational footprint — one binary, one process, a 512 MB VPS.
• Your project is small-to-medium and a single node's ceiling is fine.
• You value trivially simple backups and upgrades over platform breadth.

Pick Supabase if…

• You need real Postgres — SQL, extensions, row-level security — and the ecosystem that comes with it.
• You expect to scale beyond one node or need heavy concurrent writes.
• You're comfortable operating a multi-container stack in exchange for that headroom.

Running either on a VPS

Sizing is the clearest contrast in the catalog: 512 MB for PocketBase versus 4 GB for Supabase. If you're validating an idea, PocketBase on the cheapest droplet you can find is hard to argue with — you can always migrate the data into Postgres once the project proves it needs one. If the app is already serious, start on Supabase and skip the migration. Step-by-step install guides for PocketBase and Supabase are linked below.