Ask r/selfhosted which backend to run and you'll get the same two answers every time: Supabase and PocketBase. They get compared constantly, and usually badly — most comparisons treat them as interchangeable "Firebase alternatives" when they're built on fundamentally different assumptions about what a backend should be. One is a full Postgres platform you deploy as a multi-service stack; the other is a single Go binary you can scp to a $5 VPS.
If you're choosing between them for a self-hosted project in 2026, the right answer depends on your data model, your traffic shape, and how much operational work you're willing to own. This post lays out the differences honestly — including where PocketBase genuinely wins.
The Architecture Gap Is the Whole Story
Almost every practical difference between these two platforms traces back to one decision: the database.
PocketBase is a single executable — Go application, embedded SQLite database, admin UI, auth, file storage, and realtime subscriptions, all compiled into one binary of a few dozen megabytes. There is no orchestration because there is nothing to orchestrate. ./pocketbase serve and you're live.
Supabase is a suite of independent services built around a full PostgreSQL server: GoTrue for auth, PostgREST for the auto-generated API, Realtime for subscriptions, Storage for files, and an API gateway in front — which, as of the week of August 9, 2026, is Envoy instead of Kong by default. Self-hosting it means running roughly a dozen containers via Docker Compose.
Neither approach is "better." They're optimized for different failure modes. PocketBase minimizes the number of things that can break. Supabase minimizes the number of things your database can't do.
Quick Comparison
| Supabase (self-hosted) | PocketBase | |
|---|---|---|
| Database | PostgreSQL | Embedded SQLite |
| Deployment | Docker Compose, ~12 services | Single binary |
| Minimum server | 2 vCPU / 4 GB realistically | Runs on 512 MB |
| API | Auto-generated REST + GraphQL | REST, JS/Dart SDKs |
| Auth | Email, phone, 20+ OAuth providers, SAML, MFA | Email + OAuth2 |
| Extensions | pgvector, PostGIS, pg_cron, and dozens more | None (SQLite) |
| Realtime | Postgres replication-based | SSE-based subscriptions |
| Horizontal scaling | Read replicas, and Multigres sharding in preview | Single node, full stop |
| Ops burden | Real — updates, backups, monitoring | Minimal |
| Maturity | v2 stack, massive ecosystem | Still pre-1.0 |
Where PocketBase Wins
Let's start with the case against Supabase, because it's real.
Operational simplicity. A PocketBase deployment is one systemd unit. Backup is copying a directory (SQLite plus your uploads). Upgrading is replacing a binary. There are no inter-service version compatibility questions, no gateway configuration, no environment variable sprawl. If your project is a hobby app, an internal tool, or a prototype, this is a legitimate engineering argument, not laziness.
Resource footprint. PocketBase idles at tens of megabytes of RAM. A full Supabase stack wants 4 GB to breathe — you can squeeze it onto smaller servers by disabling services, but you're fighting the platform's assumptions. On a Raspberry Pi or the smallest VPS tier, PocketBase simply fits and Supabase doesn't.
Read performance on one node. SQLite reads are in-process — no network hop, no connection pool. For read-heavy apps on a single server, PocketBase is startlingly fast.
If that describes your project, use PocketBase. Seriously. The worst outcome in this comparison is running a twelve-container stack to serve a guestbook.
Where Supabase Wins
It's real Postgres. This is the argument that ends most evaluations. Supabase gives you an actual PostgreSQL server: window functions, CTEs, triggers, stored procedures, and the extension ecosystem — pgvector for AI workloads, PostGIS for geospatial, pg_cron for scheduling. SQLite is an excellent embedded database, but it is not a platform you build a data-heavy product on.
Concurrent writes. SQLite serializes writers — one write transaction at a time, per database. PocketBase mitigates this with WAL mode and careful internals, and for most small apps you'll never notice. But if your app has bursty, write-heavy traffic (chat, telemetry, anything social), you will eventually hit the wall, and there is no configuration flag on the other side of it. Postgres handles concurrent writers natively.
A growth path. A single PocketBase node is the whole story — there's no replication or failover; scaling means a bigger server. Supabase self-hosted supports read replicas today, and Supabase's Multigres project — the Vitess-style sharding layer for Postgres previewed alongside their $500M Series F in June 2026 — points at genuine horizontal scale down the road. You may never need it. But "we outgrew our backend" is a much worse problem than "our backend is overkill."
Auth depth. PocketBase covers email/password and OAuth2, which is plenty for many apps. Supabase's GoTrue adds phone auth, magic links, SAML SSO for enterprise customers, MFA, and anonymous sign-ins. If B2B customers are in your future, SSO requests arrive sooner than you'd think.
Row Level Security. Supabase authorization lives in the database as RLS policies — SQL rules enforced regardless of which client connects. PocketBase uses per-collection API rules, which work well but are enforced at the application layer and expressed in its own filter syntax. RLS is harder to learn and much harder to outgrow.
Maturity and ecosystem. In 2026 Supabase is a $10.5B company with a huge community, and the self-hosted stack — while it lags cloud on some features — is production-proven. PocketBase remains a largely one-maintainer project that still hasn't shipped 1.0, and its release history includes breaking changes between minor versions. It's excellent software, but "load-bearing dependency maintained by one person" is a risk you should price in deliberately.
The Honest Cost Comparison
PocketBase's pitch is that it runs on a $5/month VPS, and that's true. But the comparison people actually make — PocketBase VPS vs Supabase Cloud — is the wrong one. Self-hosted Supabase runs comfortably on a $10–20/month VPS from any of the usual providers, with no per-project fees and no usage-based pricing. We've broken down the real numbers in the true cost of self-hosting Supabase.
The genuine cost difference isn't the server — it's your time. And that's the gap tooling exists to close. The reason people reach for PocketBase is rarely "I love SQLite"; it's "I don't want to babysit twelve containers." Supascale exists to remove exactly that burden from self-hosted Supabase: automated S3 backups with one-click restore, custom domains with automatic SSL, OAuth provider configuration through a UI instead of environment variables, and selective service deployment so you only run the services you actually use. It's a one-time license from $99 with unlimited projects — the pricing is deliberately not a subscription, because a self-hosted stack shouldn't have a cloud bill attached.
With the ops burden handled, the decision collapses back to the technical question: SQLite or Postgres?
How to Actually Decide
Choose PocketBase if:
- The project is a prototype, hobby app, or small internal tool
- One modest server will always be enough
- Your data model is simple and your write volume is low
- You value "one binary, one directory" above everything else
Choose self-hosted Supabase if:
- Your data is relational and your queries are non-trivial
- You need Postgres extensions — vector search, geospatial, cron
- Concurrent writes, replicas, or eventual horizontal scale are plausible futures
- You need serious auth: SSO, MFA, phone, or fine-grained RLS
- You're building something you expect to still be running in five years
A pattern worth naming: plenty of developers prototype on PocketBase and rebuild on Supabase when the app gets traction. That's a fine path — but if you already know the app is relational and multi-user, starting on Postgres saves you a migration that always lands at the worst possible time. Check the system requirements — a 4 GB VPS is a lower bar than most people assume.
The Takeaway
PocketBase and Supabase aren't really competitors; they're answers to different questions. PocketBase asks "what's the least backend I can run?" and answers it brilliantly. Supabase asks "what if your backend was just Postgres, with everything wired up?" — and self-hosted, that buys you an open platform with no ceiling and no vendor bill.
Pick based on where your project will be in two years, not where it is this weekend. And if the twelve-container stack is the only thing pushing you toward the smaller tool, that's a tooling problem — one that's already solved.