Supabase vs PocketBase for Self-Hosting

researchself-hostingbackendsupabasepocketbase

Bottom line

For a self-hosted backend, PocketBase is the simplest and cheapest operationally. Supabase is more capable and more production-scalable if you can operate a multi-service Postgres stack. PocketBase is best for MVPs, internal tools, solo projects, and small-to-medium apps that can run on one server. Supabase is better for relational complexity, SQL power, row-level authorization, GraphQL/REST APIs, Edge Functions, Postgres extensions, and workloads that may need stronger scaling paths. The main caveat: self-hosted Supabase is community-supported and lacks some managed-platform features. PocketBase is pre-v1 and explicitly not recommended by its docs for production-critical apps unless you accept manual migration work.

Key findings

  • PocketBase wins on self-hosting simplicity. it's a single Go executable with SQLite, auth, realtime, file storage, admin UI, and REST-ish API.
  • Supabase wins on capability depth. It provides Postgres, Auth, PostgREST REST API, GraphQL, Realtime, Storage, Edge Functions, pgvector/AI tooling, and mature client libraries.
  • Supabase self-hosting has real ops overhead. Official docs recommend Docker Compose, 4 GB RAM minimum / 8 GB+ recommended, and responsibility for backups, HA, monitoring, security, and updates.
  • PocketBase has a scale and maturity ceiling. It uses SQLite, is single-server oriented, has no horizontal scaling story, and is still pre-v1 with no full backward compatibility guarantee.

Quick comparison

Area Supabase PocketBase
Core database PostgreSQL SQLite
Deployment Docker Compose multi-service stack Single binary; optional Docker
Self-host complexity Medium/high Very low
Auth Supabase Auth / GoTrue, OAuth, JWT, MFA options Built-in auth, OAuth2, users/admins
Authorization PostgreSQL Row Level Security Collection API rules/filters
API Auto REST via PostgREST, GraphQL via pg_graphql REST-ish API
Realtime WebSocket engine over Postgres changes Realtime subscriptions
File storage Storage API; S3-compatible options Local or S3-compatible storage
Functions/custom logic Edge Functions, DB functions Go extension framework, JavaScript hooks
Admin UI Studio Built-in dashboard
Official SDKs JS/TS, Flutter, Swift, Python; community more JS and Dart official
Scaling path Postgres/server architecture; more scalable but more ops Mostly vertical/single-server
Production caveat Self-hosted lacks some platform features and is community-supported Docs warn not production-critical before v1.0
Best fit SaaS, relational apps, SQL-heavy apps, larger teams MVPs, internal tools, indie apps, low-ops self-hosting

Background

Both tools are open-source Backend-as-a-Service-style platforms: they bundle common backend needs such as database, auth, storage, realtime updates, APIs, and admin tooling.

Supabase describes itself as a Postgres development platform and “Firebase-like” developer experience built from open-source tools. Its architecture includes Postgres, Studio, GoTrue/Auth, PostgREST, Realtime, Storage, Edge Runtime, postgres-meta, Supavisor, and Kong.

PocketBase is an open-source Go backend “in 1 file.” It embeds SQLite and includes realtime subscriptions, auth, file/user management, an admin dashboard, and a REST-ish API. It can run as a standalone app or be used as a Go framework.

Current state

Supabase self-hosting is officially supported through Docker Compose. The docs say it's a fit when you need full data control, compliance isolation, or an isolated environment. Also clarify that the self-hosted version mimics a single project and lacks several managed-platform-only features.

PocketBase is actively developed; the releases page shows v0.39.0 as the latest release, and the docs currently link v0.39.0 binaries. But PocketBase’s own docs warn it's still under active development, full backward compatibility isn't guaranteed before v1.0.0. It isn't recommended for production-critical applications unless you're comfortable following changelogs and doing manual migrations.

Technical or implementation details

Supabase

Supabase is built around PostgreSQL. It exposes database tables through REST via PostgREST and GraphQL via pg_graphql, supports realtime database change streams, and integrates auth with PostgreSQL Row Level Security.

Important self-hosting details:

  • Official path: Docker Compose.
  • Minimum resources: 4 GB RAM, 2 CPU cores, 50 GB SSD.
  • Recommended: 8 GB+ RAM, 4 CPU cores+, 80 GB+ SSD.
  • APIs exposed through Kong gateway: REST, Auth, Storage, Realtime, Functions.
  • Production HTTPS generally requires a reverse proxy.
  • You manage secrets, SMTP, backups, monitoring, updates, HA, and scaling.

Supabase’s authorization strength is Postgres RLS. Policies are SQL rules attached to tables and act like implicit WHERE clauses. This is powerful and portable, but can add complexity and performance concerns if policies are poorly indexed or written.

PocketBase

PocketBase’s architecture is intentionally minimal:

  • One executable.
  • Embedded SQLite database.
  • pb_data stores app data and uploaded files.
  • pb_migrations stores migration files.
  • Admin UI at /_/.
  • API under /api/.
  • Can be extended with JavaScript hooks or used as a Go framework.

Production docs emphasize portability: upload the binary and run it, optionally with systemd, reverse proxy, Docker, backups, SMTP, rate limiting, superuser IP whitelists, MFA/OTP, and file descriptor tuning for many realtime connections.

PocketBase authorization uses API rules per collection: listRule, viewRule, createRule, updateRule, and deleteRule. Rules can be locked, public, or filter expressions using collection fields and request data such as @request.auth.id.

Evidence, comparisons, and related context

SQLite’s own guidance is helpful for PocketBase: SQLite works well for low-to-medium traffic websites and application-specific server-side databases, but client/server databases are recommended for many concurrent writers, write-heavy high-volume websites, multi-server setups, and very large datasets.

That maps cleanly to the decision:

  • If your backend can live on one server and writes aren't extreme, PocketBase’s SQLite model can be practical.
  • If you need multiple services, larger datasets, complex queries, stronger concurrency, or SQL-first workflows, Supabase’s Postgres model is a better fit.

Independent/competitor benchmarking should be treated cautiously. TrailBase’s benchmark page reports PocketBase and TrailBase using roughly 90–150 MB in its tests while self-hosted Supabase used several GB. The author explicitly warns benchmarks are workload-dependent and not universally predictive. The safer conclusion is supported by official docs: Supabase is materially heavier because it runs many services; PocketBase is materially lighter because it's one process.

Limitations and critiques

Supabase limitations

  • Self-hosted Supabase is community-supported.
  • Studio doesn't support multiple organizations/projects in self-hosted mode.
  • Platform-only features unavailable self-hosted include branching, advanced metrics beyond logs, managed backups/PITR, analytics/vector buckets, ETL, and platform management API.
  • More moving parts: Postgres, Kong, Auth, Realtime, Storage, Edge Runtime, Logflare/Vector, Supavisor, etc.
  • Requires real DevOps for security, monitoring, backups, updates, and HA.

PocketBase limitations

  • Pre-v1; backward compatibility not guaranteed.
  • Docs warn against production-critical use unless you accept changelog/migration work.
  • SQLite means no easy horizontal scaling and only one writer at a time at the DB-file level.
  • Maintainer discussion says PocketBase may not fit write-heavy, high-availability, or horizontal-scaling use cases.
  • Fewer official SDKs and less enterprise support than Supabase.
  • No Supabase-style Edge Functions; custom logic is via Go framework use or JS hooks.

Open questions

  • How much production-critical risk are you willing to accept from PocketBase’s pre-v1 status?
  • Do you need managed-like features such as PITR, branching, observability, and multi-project dashboards, or is a simple self-hosted stack enough?
  • What is your expected write concurrency and realtime connection count?
  • Will your data model benefit from full PostgreSQL, extensions, joins, SQL migrations, and RLS?
  • Who will own backups, monitoring, security patching, and incident response?

Practical takeaways

  • Choose PocketBase if you want the fastest self-hosted path, minimal infrastructure, low cost, simple CRUD/auth/storage/realtime, and can tolerate single-server scaling.
  • Choose Supabase if you need Postgres, SQL, RLS, GraphQL/REST APIs, Edge Functions, richer SDK ecosystem, and a more scalable foundation.
  • For serious production, test your own workload. Especially benchmark writes, realtime subscriptions, backup/restore, and migration workflow.
  • If self-hosting Supabase, budget for DevOps. If using PocketBase, budget for pre-v1 upgrade discipline.

Sources used