Is one server the right boundary?
PocketBase combines SQLite, user and file management, realtime subscriptions, an admin dashboard, and a REST-ish API in a backend that can run as one executable. That makes it worth evaluating when you want to operate a small backend without a separate database server.
The boundary matters as much as the packaging. The FAQ describes vertical scaling on a single server and says there are no plans to support databases other than SQLite. Choose it only if that architecture fits your application and recovery requirements. We did not measure application capacity or establish a maximum workload.
The README documents standalone use, JavaScript extensions through the included VM, and use as a Go library. Official client SDKs cover JavaScript and Dart. These are ways to build around PocketBase; they do not change its single-server scaling model.
What our recorded run establishes
Our stored run took place on October 4, 2026, at commit 5cec579da984436a258602a46a96302fbd31f77c, associated with release v0.40.4. No new execution was performed for this review.
| Recorded step | Observation | Limit |
|---|---|---|
| Dependency/setup | Exit 0 in 30 seconds; 80 dependencies recorded | The tail shows a Go 1.27.0 toolchain download, not confirmation that a PocketBase executable was installed |
| Build-labelled step | Exit 0 in 79 seconds | The tail also reports a vet diagnostic and vet-exit:1; this was not clean validation |
| Tests | Exit 0 in 244 seconds | The parser reports package results, not individual test cases; complete-log reconciliation was not performed |
The test parser recorded 68 successful package results, zero failed package results, and 10 packages without test files. The retained output includes package-level ok lines and [no test files] entries. Packages without test files are not failed tests. The summary does not establish exhaustive unique test coverage.
The build tail identifies a struct field with a JSON tag that is not exported in tools/router/unmarshal_request_data_test.go:454:3. Its vet-exit:1 marker needs investigation before calling validation clean. It does not, by itself, prove that PocketBase cannot build or run.
The sandbox configuration records 3 CPUs, 8 GB of memory, and the image golang:1.24-bookworm. The setup tail explicitly shows go: downloading go1.27.0 (linux/amd64). Follow the README's Go 1.27+ requirement; the base-image name is not evidence that the project works with Go 1.24.
The checkout measured 829 files, approximately 188,877 lines of source, and 13 MB. Detection found one CI workflow and a tests directory, with no Dockerfile or Compose file. These describe the checkout, not the size of a release executable or the completeness of its validation. No installed-binary check, service startup, HTTP request, concurrency test, production workload, or security audit is recorded.
Deployment still needs an operating plan
The supplied production guide, labelled v0.41.0, describes uploading the executable and running it without external dependencies. That documentation is separate from our measured v0.40.4-associated checkout.
Preserve pb_data on persistent storage. The guide says built-in backups are ZIP snapshots of that directory, including locally uploaded files but excluding files uploaded to S3 and local backup archives. If uploads use S3, the backup plan must cover those objects separately. The guide warns that backup work can slow queries and suggests considering another strategy for large data directories, giving 5 GB or more as an example rather than a hard limit.
The same guide recommends SMTP for reliable mail delivery, rate limiting, and restrictions on superuser IPs. Reverse-proxy deployments may need client-IP header configuration. Open-file limits may need adjustment for many concurrent realtime connections. These are documented operating considerations, not security findings from our run.
Compatibility and support affect the decision
The README warns that full backward compatibility is not guaranteed before v1.0.0. Pin a release, read its migration notes, and rehearse upgrades against a copy of application data before replacing the executable.
Release v0.40.4 documents a fix for a migration deadlock. That specific fix is useful release history; it does not establish that every migration path or workload is reliable. The FAQ describes PocketBase as a personal project developed entirely by volunteers, without promises of maintenance or support. Repository attention cannot substitute for those commitments.
Configuration also needs a precise reading. Issue 7504 requests an environment-variable interface for all settings, but the maintainer says environment variables can already be loaded as initial settings through Go or the JavaScript VM, including initialization on each application start. Teams requiring configuration through environment variables should assess that code-based route rather than assume the dashboard is the only option.
The supplied WebAuthn issue remains open and appears in the backlog. Comments mentioning external implementations do not establish built-in support. If passkeys are essential, confirm the implementation you intend to deploy before adopting PocketBase.
When to consider another platform
Supabase is relevant when PostgreSQL or hosted operation is a requirement. Its repository describes a Postgres platform with authentication, APIs, realtime subscriptions, functions, and storage, alongside hosted, self-hosted, and local development options. We did not compare its performance or operating cost with PocketBase.
Appwrite is relevant when you want functions, messaging, or frontend hosting alongside backend services. Its repository documents managed cloud and self-hosting; the self-hosted installation requires Docker. We did not run that installation or measure its deployment effort.
How to read the scores
These are editorial fit ratings, not benchmark results. The rubric is: 1 means the evidence shows a major obstacle; 2 means substantial constraints or unresolved validation; 3 means a documented option with material limits; 4 means strong documented support with bounded gaps; 5 requires comprehensive evidence for the intended use. Missing adoption or compatibility evidence does not earn a high score.
Setup receives 3/5 because standalone deployment is documented and the recorded steps completed, while binary operation was not checked and the vet marker remains unresolved. Documentation receives 4/5 for concrete deployment, backup, extension, and limitation guidance, with the current guide's version kept separate from the measured commit. Community receives 3/5 because public help and maintainer responses are documented, but support is voluntary and response reliability was not measured. Maturity receives 2/5 because compatibility is explicitly unguaranteed before v1.0.0 and the run does not validate production behavior.
Before committing, check the selected release's requirements, investigate the vet diagnostic, start the actual executable, and exercise your application's authentication, access rules, uploads, backup restoration, and upgrade path. Those checks remain work for the adopting team; this record does not show them completed.