PocketBase: A Single-File Go Backend for Small Teams and Prototypes

What PocketBase Actually Solves

PocketBase targets developers who want a backend without operating a server fleet or wiring together separate services. It packs an embedded SQLite database, realtime subscriptions, file storage, user authentication, and an admin dashboard into a single executable. The README pitches it as an open source Go backend, and the core value is operational simplicity: you run one binary and you get a REST-like API, a UI for managing data, and realtime push updates. This is for small teams, solo developers, and anyone building a prototype or an internal tool who does not want to maintain a separate database server, an auth service, and a file storage bucket. It is not aimed at large-scale deployments or teams that need horizontal scaling out of the box.

The Architecture: One Binary, Two Modes

PocketBase works in two distinct ways, both visible in the repository. The first is a standalone app: you download a prebuilt executable from the Releases page and run `./pocketbase serve`. That executable is built from the `examples/base/main.go` file and includes the JS VM plugin, which lets you extend PocketBase with JavaScript. The second mode is as a Go framework. You import `github.com/pocketbase/pocketbase` and write a `main.go` that creates an app instance, hooks into serve events, and registers custom routes. The README shows a minimal example where `app.OnServe().BindFunc` adds a `GET /hello` route. Under the hood, PocketBase uses an embedded SQLite database, and the realtime subscriptions are part of that core. The data flow is straightforward: clients talk to the REST-ish API, the server reads and writes to SQLite, and realtime subscriptions push changes over a websocket or similar mechanism, though the README does not specify the transport details.

Running It: Commands and Configuration

Getting PocketBase running requires only a few commands. For the standalone route, download the archive for your platform, extract it, and run `./pocketbase serve`. For the Go framework route, you need Go 1.27 or higher. The README gives a four-step process: create a directory with a `main.go` file, run `go mod init myapp && go mod tidy` to pull dependencies, then `go run main.go serve` to start. To build a static executable, use `CGO_ENABLED=0 go build` and run the resulting binary with `./myapp serve`. The same command works inside the `examples/base` directory to build the minimal standalone binary. Cross-compilation is supported for a range of platforms, including linux on amd64, arm64, riscv64, and s390x, as well as windows and darwin variants. The pure Go SQLite driver limits the target matrix, but the listed table covers most common deployment environments.

The Real Realtime: What Subscriptions Give You

Realtime subscriptions are a headline feature, but the README gives no protocol details. It says the embedded database includes realtime subscriptions, and the API SDKs for JavaScript and Dart are the recommended way to interact with them. That means you get push updates when records change, which is useful for chat apps, live dashboards, or collaborative editing. The limitation is that PocketBase's realtime model is tied to its own API and SDKs. If you need to integrate with a custom realtime protocol or a non-official client, you are on your own. The documentation at pocketbase.io/docs would have the specifics, but the README alone does not describe how subscriptions are scoped, filtered, or authenticated. For a production system, you would need to verify those details before relying on the feature.

Extending with Go and JavaScript: Two Paths, Different Trade-offs

PocketBase offers two extension mechanisms, and they are not equal. The Go framework path lets you register custom routes and hook into serve events, as shown in the `OnServe().BindFunc` example. That gives you full control over request handling and business logic, but it means you are writing Go and compiling a custom binary. The JavaScript path, enabled by default in the prebuilt executables, lets you extend the app with JS scripts. That is lower friction for quick changes, but the README warns that the JS VM plugin is part of the base example, not necessarily the core library. The trade-off is clear: Go extensions are type-safe and compiled, but require a Go toolchain; JS extensions are easier to iterate on but add a runtime dependency and potential performance overhead. The documentation at pocketbase.io/docs/js-overview/ would clarify the JS API surface, but the README does not.

A Genuine Limitation: Pre-1.0 Instability

The README carries a warning box: PocketBase is under active development and full backward compatibility is not guaranteed before v1.0.0. That is a real constraint, not a formality. The release history shows v0.40.1 and v0.40.0 released on consecutive days, which suggests rapid iteration and frequent breaking changes. If you build on PocketBase today, you must budget time for upgrading and fixing code when APIs shift. The project also has a roadmap, but the README does not state a timeline for v1.0.0. For a long-lived project, this instability is a serious risk. For a prototype or a short-lived internal tool, it is acceptable. The README also notes that PRs are temporarily disabled due to LLM spam, which means external contributions are limited right now, another sign that the project's governance is in flux.

Alternatives: Supabase and Direct SQLite

The closest alternative is Supabase, which also provides an API, realtime subscriptions, and user management, but it is a hosted service built on PostgreSQL. PocketBase gives you a self-contained binary and SQLite, while Supabase gives you a managed Postgres database with row-level security and a larger ecosystem of extensions. The difference in approach is fundamental: PocketBase is a single-file embedded backend you control entirely, while Supabase is a platform you connect to over the network. If you need Postgres features like complex joins, full-text search, or geographic queries, Supabase is the better fit. If you want zero external dependencies and offline capability, PocketBase wins. Another alternative is using SQLite directly with a lightweight HTTP framework like Express or Fiber, but then you lose the admin UI, realtime, and auth that PocketBase provides out of the box.

Maintenance, Upgrade Cost, and License

Maintenance cost is tied to the pre-1.0 instability. Each release can introduce breaking changes, so you should read the release notes before upgrading. The project is actively maintained, with the last push on 2026-08-24 and multiple releases that week, so you can expect frequent updates. The license is MIT, which the README highlights as allowing you to do whatever you want, even offer it as a paid service. That is a permissive license with no copyleft obligations, which simplifies commercial use. However, the README also says the project is developed by a single maintainer who closes PRs he does not want and has disabled PRs entirely for now. That means you should not rely on community patches landing quickly. You will need to fork and maintain your own changes if you hit a bug that the maintainer does not prioritize.

Editorial conclusion

Adopt PocketBase if you need a self-contained backend for a prototype, an internal tool, or a small production app where the pre-1.0 API churn is acceptable. Do not adopt it if you require guaranteed backward compatibility, complex relational queries, or a large ecosystem of plugins. Before committing, verify the current release notes for breaking changes, check the roadmap for the path to v1.0.0, and test your specific realtime and file-handling patterns against the latest version.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes