PocketBase is described by its own documentation as “an open source backend consisting of embedded database (SQLite) with realtime subscriptions,” with builtin auth management, a dashboard UI at /_/ and a REST-ish API at /api/. You download an executable, run ./pocketbase serve, and you have a backend.
There is one sentence in those docs that should decide the conversation before any feature comparison, and it is easy to miss.
The sentence to read first
From the official documentation:
“PocketBase is NOT recommended for production critical applications yet.”
And immediately relevant alongside it:
“full backward compatibility is not guaranteed before reaching v1.0.0”
This is the project telling you, in its own words, where the line is. It is not a disclaimer buried in a licence file; it is in the introduction to the docs. Taken seriously, it sorts the use cases cleanly: prototypes, internal tools, side projects, demos and anything you could rebuild in an afternoon are fair game. The system of record for a business is not — not because PocketBase is bad, but because its authors have declined to make that promise and you would be making it on their behalf.
Teams routinely ship PocketBase anyway, and often fine. The point is that if it goes wrong you cannot say you were not told.
“One file” is true of the binary, not of the deployment
The distribution model is unusually austere, and it is worth being precise about what it includes. The docs say the “easiest way to get started is to download the prebuilt minimal PocketBase executable,” offering zip archives for Linux, Windows and macOS on x64 and ARM64, with other platforms on the GitHub releases page.
What the documentation does not mention: a package manager, a Homebrew formula, or a Docker image. There is no apt install, no brew install, no official container. The supply chain is a zip file you fetch and verify yourself, which is refreshingly simple and also means updates are a thing you do manually, on purpose, with no automation unless you build it.
Nor is the running system one file. State lives in a pb_data directory next to the executable — the SQLite database plus “uploaded files, etc.” The binary is stateless and disposable; pb_data is the whole product. That distinction is the single most important operational fact about PocketBase, because it tells you exactly what a backup is: that directory, consistently, while the process is not mid-write.
If PocketBase runs in a container, that is a named volume, and a sidecar like docker-volume-backup handles it — including stopping the container during the snapshot so the SQLite file is not caught mid-transaction. If it runs on a host, it is a directory and any snapshot tool will do. Either way, decide this on day one, because “one file” invites people to assume there is nothing to back up.
The second mode nobody uses at first
The docs note PocketBase “can be used both as Go framework and as standalone application.”
That matters more than it sounds. The standalone binary is a product with fixed behaviour; the framework is an import in your own Go program, where you keep the database, auth, realtime and admin UI but add your own routes, hooks and business logic. Teams usually arrive via the binary, outgrow one specific constraint, and discover that the escape hatch is a Go module rather than a migration to something else.
If you expect to need custom server-side logic, start in framework mode. Starting with the binary and migrating later means rebuilding your deployment, not just your code.
What it is actually competing with
PocketBase is the smallest serious answer to “I need auth, a database, file uploads and realtime, and I do not want to assemble four services.” Its competitors are not other SQLite tools; they are hosted platforms.
Against Supabase, the trade is Postgres and a managed option against one process you can carry on a USB stick. Against Appwrite, it is breadth of SDKs and services against a single binary with no orchestration. PocketBase wins decisively on time-to-first-request and loses on everything that scales horizontally, because an embedded database on one disk is exactly as available as that disk.
Where this leaves it
The honest recommendation: use PocketBase freely for anything you could lose and recreate, treat the production warning as the operating constraint rather than boilerplate, and define your pb_data backup before you write the first collection.
The finding from reading the docs rather than the pitch: the thing most people repeat about PocketBase — that it is a single file — is true of the download and false of the deployment, and the project’s own documentation tells you not to put critical data in it yet. Both facts are in plain sight and neither usually survives the retelling.
Primary link
Learn more at: https://github.com/pocketbase/pocketbase
