# PocketBase: a realtime backend in one Go binary, SQLite included

> PocketBase ships an embedded SQLite database, realtime subscriptions, file and user management and an admin dashboard inside a single executable. It is a good fit for small self-hosted apps, but the pre-1.0 warning in the README is not decoration.

**pocketbase/pocketbase** — PocketBase is an open-source Go backend in one file, with an embedded SQLite database, realtime subscriptions, user and file management, an admin UI, and a REST-ish API.

- Repository: https://github.com/pocketbase/pocketbase
- Website: https://pocketbase.io
- Stars: 61,208 · Forks: 3,707
- Language: Go
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/pocketbase-pocketbase

## What PocketBase actually replaces

The README describes PocketBase as an open source Go backend that includes an embedded SQLite database with realtime subscriptions, built-in files and users management, an admin dashboard UI, and a REST-ish API. Read that list as a bill of materials rather than a feature list. Each item is something you would otherwise assemble yourself: a database process, a migration tool, an auth layer with password reset and OAuth flows, an object store for uploads with thumbnails, a websocket or SSE channel for live updates, and an internal admin screen for editing rows.

The target user is someone building a small application who does not want to operate that stack. A single-tenant internal tool, a mobile app backend, a prototype that needs a real database and real auth on day one. The prebuilt executables are described as being based on examples/base/main.go and come with the JS VM plugin enabled by default, so you can extend the server with JavaScript without compiling anything. For Go developers the same code is published as a regular library package, which means the boundary between "framework" and "your application" is a main.go file you own.

The trade-off is scope. PocketBase is not a general purpose database platform and the README does not present it as one. Everything it offers is tied to SQLite running in the same process as the HTTP server.

## One process, one SQLite file, one HTTP server

The architecture is visible in the repository layout. Top-level directories include apis/, core/, forms/, migrations/, mails/, plugins/, tools/ and ui/, with a single pocketbase.go at the root and cmd/ for the CLI. The UI is embedded, which is why the admin dashboard ships inside the binary rather than as a separate deployment.

The Go module file confirms the storage engine: modernc.org/sqlite, a pure Go SQLite driver. That choice is what makes CGO_ENABLED=0 builds possible, and it is also what limits the platform matrix. The README publishes a table of supported GOOS and GOARCH combinations for the pure Go SQLite driver, covering darwin, freebsd, linux, netbsd, openbsd and windows across a range of architectures including linux/loong64, linux/ppc64le, linux/riscv64 and linux/s390x. If your deployment target is not in that table, the build story changes.

Other dependencies hint at the runtime surface: dop251/goja and dop251/goja_nodejs provide the JavaScript VM, pocketbase/tygoja bridges Go types into that VM, golang-jwt/jwt/v5 handles tokens, golang.org/x/oauth2 covers OAuth providers, disintegration/imaging and golang.org/x/image handle image processing for uploads, and domodwyer/mailyak/v3 sends mail. The fexpr and dbx packages are the query and database layers. Nothing here is exotic, and nothing here is a distributed system component. State lives in the SQLite file and in the uploads directory next to it.

## Installing PocketBase and serving a first route

There are two installation paths, and they lead to different working styles. The first is the prebuilt executable. The README says to download the archive for your platform from the Releases page, extract it, and run the serve command inside the extracted directory. The second is to use PocketBase as a Go library, which requires Go 1.27 or later according to the README.

The standalone path is the shorter one. After extracting the archive:

```bash
./pocketbase serve
```

The server starts and, per the documentation, the admin dashboard is reachable from the same process. The binary is based on examples/base/main.go and includes the JS VM plugin by default, so hooks and routes can be written in JavaScript from the dashboard without a rebuild.

The library path gives you a main.go you control. The README's minimal example registers a new route on the serve event:

```go
package main

import (
    "log"

    "github.com/pocketbase/pocketbase"
    "github.com/pocketbase/pocketbase/core"
)

func main() {
    app := pocketbase.New()

    app.OnServe().BindFunc(func(se *core.ServeEvent) error {
        se.Router.GET("/hello", func(re *core.RequestEvent) error {
            return re.String(200, "Hello world!")
        })

        return se.Next()
    })

    if err := app.Start(); err != nil {
        log.Fatal(err)
    }
}
```

To initialize dependencies and run it, the README gives three commands:

```bash
go mod init myapp && go mod tidy
go run main.go serve
CGO_ENABLED=0 go build
```

The first command creates the module and resolves dependencies. The second starts the application with the serve subcommand. The third produces a statically linked executable, which you then start with ./myapp serve. If you prefer to build the reference example instead of writing your own main.go, the README says to navigate to examples/base and run CGO_ENABLED=0 go build, then start the result with ./base serve. Cross-compilation uses the standard Go variables, for example GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build.

For client-side work, the README points at two official SDKs: pocketbase/js-sdk for browser, Node.js and React Native, and pocketbase/dart-sdk for web, mobile, desktop and CLI. It also refers readers to the how-to-use page on the project site for other recommendations.

## The pre-1.0 warning is the main operational risk

The README carries a warning block that states PocketBase is still under active development and that full backward compatibility is not guaranteed before reaching v1.0. That sentence should drive your upgrade policy more than any feature comparison. The recent release history shows the practical shape of it: v0.40.1 and v0.40.0 landed on consecutive days in August 2026, and a v0.22.53 release was published alongside them, which indicates a maintained branch on the older 0.22 line rather than a single moving target.

The repository also keeps three archived changelogs, CHANGELOG_08_15.md, CHANGELOG_16_22.md and CHANGELOG_23_39.md, next to the current CHANGELOG.md. That is a useful signal for anyone planning a jump across several minor versions: the record is split by era, and you should read the era you are leaving.

Beyond versioning, the harder limit is SQLite. PocketBase runs the database in the same process as the HTTP server, so scaling out means running more instances, and each instance has its own file. There is no documented multi-node write coordination. If your workload requires many application servers writing to one primary database over a network, PocketBase is the wrong tool and no amount of Go code around it changes that. The same applies if you need a database engine with a specific extension or an operational story your platform team already standardized on.

A smaller limitation sits in the contribution process. The README states that pull requests for new features should be discussed first because the project follows a roadmap, and it notes that PRs are temporarily disabled due to LLM spam, with only existing collaborators able to open one. The suggested route is to open an issue or discussion with a link to your fork. If your team's workflow depends on upstreaming patches, that is a real constraint to weigh.

## PocketBase vs Supabase and the self-hosted alternative space

The comparison people ask about most is PocketBase vs Supabase, and the difference is architectural rather than a matter of feature checklists. Supabase is built around Postgres as a separate service, with the surrounding tooling connecting to that database. PocketBase embeds SQLite in the application process and ships the whole thing as one executable. That single decision cascades: PocketBase has no separate database connection string to configure, no connection pool to tune, and no network hop between the app and the data. Supabase gives you Postgres, which means the ecosystem of extensions, clients and operational knowledge that comes with it, plus the ability to scale the database independently of the API layer.

If your reason for looking at PocketBase is "I want a backend I can drop on a small VPS and forget about", the embedded model is the point. If your reason is "I want Postgres semantics and a managed control plane", PocketBase is solving a different problem and the comparison will keep feeling lopsided.

The other realistic alternative is writing the backend yourself in Go, Node or Python against SQLite or Postgres. That is more work up front but removes the pre-1.0 upgrade risk entirely, because you own the schema and the API contract. Teams that have already been burned by a framework migration tend to pick this route. Teams that want auth, file uploads, an admin UI and live subscriptions working this week tend to pick PocketBase.

## Licence, maintenance and what an upgrade costs

PocketBase is MIT licensed. The README states you are free to do whatever you want with it, including offering it as a paid service. For most teams that removes the licensing question from the decision entirely; there is no open core split described in the repository, and no separate commercial edition mentioned. This is not legal advice, and if you are redistributing the software as part of a product you should read LICENSE.md yourself.

On maintenance, the last push to the default branch was on 2026-08-24, the same day as the v0.40.1 release. The repository is not archived. Releases are frequent enough that the changelog is the document you will actually live with. The practical upgrade cost is not the binary swap, which is trivial for the standalone deployment, but the schema and API surface. Because backward compatibility is explicitly not guaranteed before v1.0, a minor version bump can require changes to your collections, your hooks or your client code. Budget for reading CHANGELOG.md before every upgrade rather than after.

Testing your own application against the framework is supported. The README describes a mixed set of unit and integration tests and points at a testing guide for writing custom application tests, while the Makefile exposes targets that mirror the standard Go workflow:

```bash
go test ./...
```

That command is what the README gives for running the project's own tests, and the Makefile's test target adds -v --cover on top of it.

## Conclusion

Adopt PocketBase for small self-hosted apps where one SQLite file and one executable are an advantage: internal tools, prototypes, single-tenant services, and Go teams that want to add HTTP routes around an existing backend. Do not adopt it if you need horizontal write scaling across multiple nodes, a Postgres wire protocol, or a stable API surface you cannot revisit. Before committing, verify the pre-1.0 compatibility warning in the README against your upgrade plan, confirm that your target OS and architecture appear in the pure Go SQLite build target table, and decide whether you will run the prebuilt executable or vendor the module into your own main.go.

## FAQ

### Is PocketBase free?

Yes. The README states PocketBase is free and open source under the MIT License, and that you are free to do whatever you want with it, including offering it as a paid service.

### Which is better, PocketBase or Supabase?

They differ in architecture. PocketBase embeds SQLite in the application process and ships as one executable with realtime subscriptions, file and user management and an admin UI. Supabase is built around Postgres as a separate service, so the database can scale independently of the API layer.

### What are some good alternatives to PocketBase?

Supabase is the usual comparison, with Postgres as a separate service rather than an embedded SQLite file. The other option is writing the backend yourself in Go against SQLite or Postgres, which removes the pre-1.0 upgrade risk because you own the schema and API contract.

### Does PocketBase have a real-time database?

The README lists realtime subscriptions as part of the embedded SQLite database, alongside file and user management and a REST-ish API.

### How do I install PocketBase?

Download the prebuilt executable for your platform from the Releases page, extract the archive, and run ./pocketbase serve in the extracted directory. Alternatively, use it as a Go library, which requires Go 1.27 or later, and build your own main.go with CGO_ENABLED=0 go build.

### Is PocketBase good for production?

The README warns that PocketBase is still under active development and that full backward compatibility is not guaranteed before v1.0.0. It also runs SQLite inside the application process, so multi-node write scaling is not part of the documented model.

## Sources

- [Official documentation](https://pocketbase.io)
- [Official README](https://github.com/pocketbase/pocketbase#readme)
- [Project repository](https://github.com/pocketbase/pocketbase)
- [Release notes](https://github.com/pocketbase/pocketbase/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pocketbase-pocketbase