PocketBase

What PocketBase actually is

PocketBase is an open-source backend in a single executable file. Written in Go by Gani Georgiev and first released in July 2022, it bundles an embedded SQLite database, a REST-ish API generated from your schema, realtime subscriptions, user authentication, file storage, and an admin dashboard into one binary. You download it (or pull the Docker image), run ./pocketbase serve, and you have a working backend on port 8090 with a browser-based admin UI. There is no cluster to run, no ORM to configure, and no vendor account to create.

The feature set reads like a checklist for a modern app backend. Collections (tables) are defined in the dashboard or in JS migration files; every collection automatically gets CRUD endpoints with per-collection and per-record access rules expressed in a small rule language. Authentication is built in — email/password, OAuth2 across roughly 32 providers, OTP, MFA, token refresh — and lives in the same record model as your data. Realtime is delivered over Server-Sent Events: clients subscribe to a collection or record and receive create/update/delete events. File storage attaches to record fields on the local filesystem or on S3-compatible object storage. There is a built-in backup/restore tool for the database and uploads.

Two usage modes matter. As a standalone app it is the five-minute setup above. As a Go framework, you embed pocketbase.New() in your own main.go, bind hooks and routes, and ship a single custom binary — the CGO-free SQLite driver means static builds for an enormous list of platforms. For people who do not write Go, the prebuilt binaries embed a JavaScript VM: hooks, routes, and migrations live in pb_hooks/*.js and pb_migrations/*.js without recompiling anything.

Honesty check on the database row we were handed: it claimed launchYear 2026. PocketBase has been public since July 2022 (the license header reads "Copyright (c) 2022 - present, Gani Georgiev"), and the GitHub project now shows 61.5k stars and 3.7k forks. The row also undersold the storage story — S3-compatible object storage is supported — and the backups claim, since backup tooling is built in. All corrected below.

The single most important caveat is in the README: PocketBase is pre-1.0 and does not guarantee backward compatibility. v0.23 (late 2024) was a large, backward-incompatible refactor of the core Go API and hooks. Treat every minor upgrade as a migration.

Pricing: what you really pay

There is no pricing page, because the software is free. PocketBase is MIT-licensed, and the README explicitly says you may do whatever you want with it, "even offering it as a paid service". Your costs are the infrastructure you run it on — a small VPS is plenty for most workloads — plus your own time operating it.

That is not the same as "free to run". You own backups, TLS, uptime, upgrades, and security patching. If you would rather not, third-party PocketBase hosting exists (managed one-click deployments on shared or dedicated infrastructure), but those are separate vendors with separate terms; PocketBase itself sells nothing. Compare that with the hosted backend services in /category/database-hosting, where the monthly bill buys an operational team. For a solo developer or small team, the trade is usually right: one $5–10/month VPS replaces a per-seat, per-record, or per-request bill.

Where cost gets interesting is scale. SQLite on one node is cheap and fast, but scaling out is your problem — PocketBase does not shard, replicate, or cluster. When a single node stops being enough, you either buy a bigger node (which goes a long way), or you leave. There is no upgrade path into a managed HA product, and that is the real "price" at growth.

Performance & infrastructure

There is nothing to benchmark here in the traditional sense — the "infrastructure" is whatever machine you deploy to, so our /benchmarks VPS numbers are the relevant reference. What we can describe precisely is the architecture and its consequences.

SQLite is embedded and accessed through a pure-Go driver (no CGO), which is why a single static binary runs on almost anything: amd64, arm, arm64, riscv64, s390x, Windows, macOS, Linux, FreeBSD. Data lives in a pb_data/ directory next to the executable (the "one file" claim applies to the binary, not your data), and migrations live in pb_migrations/. Writes go through SQLite's single-writer model; reads are local and fast. For typical app backends — thousands to low hundreds of thousands of records, modest write rates — this comfortably outperforms a networked database because there is no network.

Realtime over SSE rather than WebSockets is a pragmatic choice: one long-lived HTTP connection per subscribed client, compatible with proxies and simple to consume via EventSource. The concurrency ceiling is bounded by open connections and the single process. Similarly, the REST API is deliberately "REST-ish" — predictable CRUD plus auth endpoints, with access rules evaluated per record.

Self-hosting means you pick where it runs: Docker on a VPS, a bare-metal box, a Raspberry Pi, or embedded in your own Go binary shipped to customers. File storage defaults to the local filesystem and moves to S3-compatible object storage when you need more than one deployment target or ephemeral disks — a sensible default path. Built-in backup tooling covers the SQLite database and uploads.

The operational reality: single node, single process, no built-in replication or failover. High availability means restoring a backup onto a new box or putting your own replication in front of SQLite. For a large share of apps that is acceptable; for anything that cannot tolerate minutes of downtime, plan for it explicitly.

Where it falls short

The pre-1.0 compatibility warning is the biggest one. The project has shipped breaking changes (v0.23's hook and core API refactor is the clearest example), and with roughly one principal maintainer, the roadmap is ultimately one person's judgement. That is not a criticism of the work — the code quality and docs are high — but it is a risk to price in. The MIT licence is your hedge: you can fork, pin, and maintain it yourself.

Scaling is the second. SQLite's single-node model means vertical scaling only; SSE connections are per-process. Multi-region, read replicas, and clustering are out of scope by design. When you outgrow a node, the migration is to a client/server database — and schema and access-rule migrations are your project.

Third: it is a backend toolkit, not a product. There is no official managed offering, no support contract, no SLA, and community support via GitHub. The ecosystem (SDKs, JS/Go extension model, community examples) is healthy and the documentation at pocketbase.io is clear and complete, but you are your own SRE.

Finally, smaller feature gaps relative to the big backend platforms: no built-in job queue or cron, no server-side rendering, and the JS VM extension path trades performance and type safety for convenience. For most of the target audience these are non-issues; for larger teams they are the difference between PocketBase and a general application framework.

Who should pick this

We would pick PocketBase for solo developers and small teams building web and mobile apps who want a real backend — auth, database, files, realtime — without operating multiple services or paying a platform tax. It is our pick for internal tools, MVPs, prototypes that graduate to production, and self-hosted products where data ownership matters. If your team already writes Go, embedding PocketBase in your own binary is one of the nicest backend development experiences available.

We would not pick it for multi-region HA requirements, for write-heavy workloads that outgrow one SQLite node, or for organizations that need contractual support and SLAs. And if you expect to scale horizontally from day one, choose a client/server database now rather than migrating later.

Key takeaways

• Single MIT-licensed Go binary: embedded SQLite, REST-ish API, auth (password, OAuth2, OTP, MFA), SSE realtime, file storage, admin dashboard — free, self-hosted.
• Public since July 2022 (not 2026 as our database row claimed); 61.5k GitHub stars, predominantly a single-maintainer project.
• Pre-1.0 with no backward-compatibility guarantee — v0.23 shipped breaking core API changes; pin versions and test upgrades.
• Storage: local pb_data/ or S3-compatible object storage; built-in backup/restore for database and files.
• Single-node by design: scaling is vertical, HA is your own operational work; costs are just your hosting bill.
• Extensible without Go via JS hooks and migrations, or embedded as a Go framework in a custom binary.

Sources

• https://github.com/pocketbase/pocketbase
• https://github.com/pocketbase/pocketbase/blob/master/LICENSE.md
• https://pocketbase.io/docs
• https://deepwiki.org/pocketbase/pocketbase
• https://repocritics.com/repos/github/pocketbase/pocketbase/wiki
• https://pkg.go.dev/github.com/pocketbase/pocketbase@v0.39.0
• https://automadocs.com/docs/pocketbase/pocketbase