One executable includes SQLite, auth, files, and an admin UI
PocketBase compresses the usual starter-backend checklist into one Go program. It has an embedded SQLite database, realtime subscriptions, user and file management, an admin dashboard, and a REST-style API. The standalone executable includes a JavaScript VM for server extensions. Go developers can import PocketBase as a package, add routes or event hooks, and compile the result into another portable executable. That is a compelling amount of backend for a personal app, internal tool, or small product.
The boundaries are unusually clear. PocketBase does not ship a customer-facing login or registration interface. Official client SDKs cover JavaScript and Dart, while other clients use the HTTP API or community packages. It does not offer hosting, cloud functions, or alternate databases. The FAQ says SQLite runs in WAL mode and that other database engines are not planned. A buyer can decide early whether that compact design matches the application instead of discovering a hidden service mesh later.
A 12.9 MB checkout builds into a portable server
commit 50f5f83 occupied 12.9 MB across 829 files and roughly 187,880 source lines. The repository contained one CI workflow and a tests directory, with no Dockerfile. PocketBase's production guide likewise says there is no official Docker image, then provides a minimal example that downloads the release binary. Container users must mount /pb/pb_data; losing that volume means losing the embedded database and locally stored files.
For the shortest trial, download a release archive and run ./pocketbase serve. Extending it in Go requires Go 1.27 or newer, then go mod tidy and a normal build. The pure-Go SQLite driver supports a long list of operating system and architecture pairs, including Linux, macOS, Windows, FreeBSD, and several ARM targets. That portability is useful for small servers, though it does not change the single-writer and single-host operating model described in the official FAQ.
What happened when we ran it
Our sandbox installed 80 Go packages in 37 seconds, then completed the build in 56 seconds. The test command ran for 394 seconds and returned exit code 1. Go test reported 32 packages passed and 1 failed out of 33. This was commit 50f5f83 in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM.
The supplied log tail does not show the name or assertion of the failed package. It shows tool packages such as router, security, subscriptions, and tokenizer passing, followed by the ui package reporting no test files and a final FAIL. We will not assign a cause the log does not contain. The result is still actionable: installation and compilation succeeded, but the complete test run for this checkout was not green on our box and took more than 6 minutes to reach that result.
Single-server scaling is a design decision
PocketBase's FAQ answers the scaling question with one word: vertical. The project is meant to run on a single server, avoiding the work of coordinating a fleet. That can be the right trade for a large class of applications. It also closes the door on teams whose availability plan requires multiple active database nodes, automatic failover, or regional writes. Litestream is suggested as a companion for replication and disaster recovery, but it does not turn PocketBase into a distributed database.
Backups need similar honesty. Built-in backup APIs create a ZIP snapshot of pb_data, including local uploaded files. The production guide warns that backup work can slow queries and recommends another strategy once pb_data reaches about 5 GB or more. Manually copying that directory requires stopping the application for transactional safety. A small deployment still needs a tested restore, an off-server copy, and monitoring for disk growth. One executable reduces moving parts; it does not remove data operations.
Production needs mail, rate limits, and protected superusers
The production guide recommends SMTP because the default Unix sendmail path may fail or land in spam. It also recommends enabling the built-in rate limiter and restricting superuser access by IP or subnet. Superuser MFA is available as an extra control. Settings such as SMTP passwords and S3 credentials are stored as plain JSON in the database unless the operator supplies a 32-character encryption key through an environment variable and starts PocketBase with the matching flag.
Those are manageable tasks on one VPS, and the documentation spells them out better than many larger backends do. A reverse proxy needs the correct client IP headers, realtime connections may require a higher file-descriptor limit than the common 1,024 default, and large uploads may justify setting GOMEMLIMIT. None of this is exotic. It is enough operational work that a production launch should not be reduced to copying the executable and opening port 8090.
Pre-1.0 changes and volunteer support are explicit limits
GitHub recorded 60,833 stars and 19 combined issues and pull requests when fetched. The last push was August 24, 2026, followed by v0.40.1 the same day. That patch fixed JSON serialization of invalid UTF-8 and an OAuth2 provider configuration merge regression. The activity is current and the visible queue is small, but release frequency does not replace a compatibility contract.
The README warns that full backward compatibility is not guaranteed before v1.0.0. The FAQ goes further: PocketBase is a personal, volunteer project, with no paid team, fixed ETAs, or maintenance and support promises. Pull requests for new features are temporarily disabled because of LLM spam, and contributors are directed to issues or discussions. Those policies are fair and candid. A company that requires contractual support, predictable deprecation windows, or influence over the roadmap should choose a different backend.
PocketBase is best when its constraints sound like benefits. One modest server, SQLite, an embedded admin interface, and a portable binary can remove weeks of setup. Our failed 33-package test run keeps this checkout from receiving an unconditional recommendation, while the pre-1.0 warning limits long-lived commitments. Prototype with it, exercise backups and upgrades, and keep the choice only if vertical scaling matches the product's expected life.