PocketBase: one Go binary, an embedded SQLite file, and no API stability promise before v1.0

The release binary is the examples/base app with the JS VM switched on

PocketBase is four things in one process: an embedded SQLite database with realtime subscriptions, files and users management, an admin dashboard, and a REST-ish API. The distribution detail worth knowing is where the downloadable binary comes from. The prebuilt executables on the releases page are built from the examples/base/main.go file in this repository, and they ship with the JS VM plugin enabled by default, which is what allows the app to be extended with JavaScript.

That gives you two routes and they are not the same product. The standalone route is a file you download, extract and run. The framework route is a Go library package: you write your own main, bind your own routes, and end up with a single portable executable carrying your business logic instead of the example one. The dashboard, auth and file handling come from the library either way, so the difference is only where your code lives.

Standalone means ./pocketbase serve, framework means go run main.go serve

The standalone route is three steps. Download the prebuilt executable for your platform from the releases page, extract the archive, and start the server from inside the extracted directory:

./pocketbase serve

The framework route starts from the example main.go. That file creates an instance with pocketbase.New(), binds a function to app.OnServe() that registers a GET /hello route on se.Router, returns a string body with re.String(200, "Hello world!") and hands control back with se.Next(), then calls app.Start() and exits through log.Fatal on error. Go 1.27 or newer is required. Once your main.go exists, initialise and run it like this:

go mod init myapp && go mod tidy

go run main.go serve

The same package runs under the go test command, and the project's own test guide covers writing application tests for it.

CGO_ENABLED=0 is what makes the binary portable, and the SQLite driver sets the platforms

The build is static on purpose, because the database is a pure Go SQLite driver rather than a C library linked in. That is what lets the same source produce a binary you can copy onto a server with nothing else on it:

CGO_ENABLED=0 go build

The go.mod pins modernc.org/sqlite at v1.60.1, and a file named modernc_versions_check.go sits at the repository root. Cross-compiling follows the usual Go variables:

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build

The price of the pure Go driver is a fixed target list, twenty rows of it: darwin on amd64 and arm64, freebsd on 386, amd64, arm and arm64, linux on 386, amd64, arm, arm64, loong64, ppc64le, riscv64 and s390x, netbsd on amd64, openbsd on amd64 and arm64, and windows on 386, amd64 and arm64. If your target is not in that table, you are back to a CGO driver and a C toolchain.

JavaScript extensions run in an embedded interpreter, and their types are generated

The JS VM plugin being on by default in the release binary is a design decision with consequences. Extensions are not a sidecar service: the interpreter is compiled into the same executable that holds the SQLite file, with goja and goja_nodejs in the module requirements alongside tygoja. The project's documentation has a page on extending with JavaScript, and the fact that the release build enables it means a downloaded binary is already capable of it without a rebuild.

The type definitions on the JavaScript side are not written by hand. A Makefile target named jstypes runs a Go program to produce them:

go run ./plugins/jsvm/internal/types/types.go

So when a Go signature changes, the JavaScript surface changes with it, and the file that describes the JavaScript API is a build artifact. The rest of the Makefile is small and worth reading before you open a pull request: lint runs golangci-lint run -c ./golangci.yml ./..., and test runs go test ./... -v --cover, with test-report adding a coverage profile and an HTML report.

v0.40.4 is not v1.0.0, and the changelog is split into four version bands

The most important sentence in this project's README is a warning: PocketBase is still under active development, and full backward compatibility is not guaranteed before reaching v1.0.0. Every tag bears that out. The recent releases are v0.40.6 on 2026-10-23, v0.22.57 on 2026-10-23 and v0.22.56 on 2026-10-08, the latter two patches on a line far behind the current one, with v0.22.57 published on the same day as v0.40.6. The repository is marked archived on GitHub and its README says the repo has moved to https://ganigeorgiev.com/pocketbase/pocketbase; the last push here was on 2026-10-26. Activity and stability are different claims, and the README makes only the warning about stability.

The changelog tells you what an upgrade will cost. Rather than one file, the root holds CHANGELOG_08_15.md, CHANGELOG_16_22.md, CHANGELOG_23_39.md and the current CHANGELOG.md, which is an admission that the version history is long enough to need splitting by band. A deployment sitting on an old release has to read across those files to find out what changed before it upgrades.

Pull requests are open to existing collaborators only, right now

Contributions are restricted, and the reason is worth stating plainly because it changes what you can plan. A prominent note says that because of recent LLM spam, pull requests are temporarily disabled and only existing collaborators can open one. If you find a problem, the project asks for an issue or a discussion with a link to your fork, and adds that LLM contributions are not welcome. The status may change if GitHub acts on the spam problem or if the maintainer moves the project.

There is a second, older rule layered on top. New feature pull requests are discouraged unless the implementation has been discussed first, with the reason given plainly: the maintainer works through issues in a specific order, and unannounced pull requests skew the planning. The project also says not to take a closed pull request personally, and promises credit in the release notes for pieces of your work used later. For a reader deciding on adoption, the practical effect is that a fix you need lives in your fork, and the cost of carrying it is yours.

Supabase and Firestore differ at the storage engine, not at the feature list

If the deciding question is which backend to pick, the difference in approach shows up at the datastore. PocketBase embeds SQLite inside one process, so the deployment unit is the executable: you copy a file to a machine, start it, and the database travels with it. Supabase is built on Postgres, which means a separate database server, SQL migrations against a networked engine, and a connection model that is not a file next to the app. A hosted document store such as Firestore sits further away again, with documents as the unit of data rather than rows.

That difference propagates into everything else. Realtime in PocketBase is a feature of the embedded database, delivered to clients as subscriptions; the same feature elsewhere depends on the provider's own channel. The project keeps its own recommendations page for how to use it, and its own warning about pre-1.0 compatibility applies to whichever route you take.

Two official SDKs, a REST-ish API, and no OpenAPI document to generate from

The client story is narrow on purpose. The official SDKs are JavaScript, covering browser, Node.js and React Native, and Dart, covering web, mobile, desktop and CLI. Other languages talk to the HTTP API directly, and the project's documentation keeps a how-to-use page with recommendations for those cases.

The API itself is described as REST-ish, and the hedge is in the project's own wording. Nothing at the top level of the repository is an OpenAPI or Swagger document, so there is no schema for a generator to consume and no published contract to diff against when you upgrade. That is the same pre-1.0 caveat seen from the other side: the changelog bands and the warning are what you have instead of a versioned contract. If your client code is generated by hand, expect to read the changelog for your band before every upgrade, and pin the server version until you have done it once.

Editorial conclusion

PocketBase suits a small product or an internal tool where one binary and one SQLite file are an advantage and a schema migration is something you can afford to do by hand. Do not adopt it for a service that needs contractual API stability, and do not plan to send patches upstream: pull requests are open to existing collaborators only, so fixes live in your fork. Before you commit, check the changelog band that covers your current version and read the compatibility warning, because the project states that full backward compatibility is not guaranteed before v1.0.0.

Frequently asked questions

Official sources

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