PocketBase in 2026: an architecture note on SQLite tables, stateless auth, realtime subscriptions, and the one-file boundary

This real server-rack photograph fits because PocketBase is most legible as an intentionally narrow self-hosted boundary: one process, one SQLite-backed application state, and one machine envelope before any larger platform story begins.[2][10]

PocketBase is easy to oversell because the tagline is so compact. "Open source backend in 1 file" sounds like a magic trick, and the homepage stacks several attractive promises right behind it: embedded database, realtime subscriptions, built-in auth, file handling, admin UI, and a simple REST-ish API.[1][5] But the project becomes much clearer once you stop reading that as a miniature Supabase or Firebase and start reading it as a very opinionated packaging choice. PocketBase is a backend that keeps several ordinary application needs inside one binary, one SQLite file, and one operational fault line.[1][2]

That boundary matters more in 2026 because the project is no longer obscure. As of 2026-04-30T21:34:19Z UTC, the GitHub API reports 58,045 stars, 3,338 forks, 18 open issues, and a most recent push timestamp of 2026-04-29T08:06:37Z for pocketbase/pocketbase.[7] The latest release is v0.37.4, published on 2026-04-27T06:55:53Z.[8] At the same time, the official docs still make two cautionary points in plain language: full backward compatibility is not guaranteed before v1.0.0, and PocketBase is not recommended for production-critical applications yet unless you are willing to read changelogs and handle migrations yourself.[1] That combination tells you almost everything about the architecture. PocketBase is powerful because it is compact. It is also compact because it refuses several kinds of complexity on purpose.

Image context: the cover uses a real server-rack photograph rather than a dashboard screenshot, abstract avatar, or architecture diagram. That choice keeps the visual emphasis on PocketBase's operational claim: a backend that stays close to one machine, one deployable unit, and one SQLite-centered boundary before it tries to become anything larger.[2][10]

The one-file promise is really one operational boundary

The docs and FAQ describe the same core idea from two angles. The docs say PocketBase can run as a standalone application or as a Go framework, while the FAQ says it was created to help people build self-contained applications on a single server without installing extra backend infrastructure.[1][2] That sounds like convenience language, but it also defines the real architecture. PocketBase is not trying to decompose itself into a database service, an auth service, a pub-sub layer, and a serverless runtime. It keeps those concerns close enough together that one process can own them.

That is why the scale answer in the FAQ is so revealing. PocketBase says it scales only vertically, on a single server, and positions that as a deliberate trade rather than an embarrassing limitation.[2] The same page claims 10,000+ persistent realtime connections on a cheap Hetzner CAX11 VPS with 2 vCPU and 4 GB RAM.[2] Whether your workload matches that exact profile is less important than the principle underneath it: PocketBase would rather be excellent inside one machine's envelope than become a distributed control plane too early.

Once you read it that way, the project's appeal sharpens. The question is no longer "Can this replace a fleet of managed backend services?" The question is "Do I benefit when CRUD, auth, file uploads, a small admin UI, and basic realtime all share one deployable unit?" For many internal tools, hobby apps, small SaaS products, and self-hosted applications, the answer is yes.[1][2][9]

Collections are generated SQLite tables, not a cloud abstraction

The collections documentation strips away a lot of mystery. Under the hood, PocketBase collections are backed by plain SQLite tables generated automatically from the collection name and fields.[3] That single sentence matters because it tells you the data model is much closer to a local application database than to a proprietary hosted document service. There are base collections, auth collections, and view collections, but all of them still live inside a SQLite-shaped world.[3]

That leads to two useful architectural consequences. First, the "backend in one file" slogan is not an abstraction floating above storage. It is grounded in SQLite as the default data substrate. Second, the admin UI is not hiding a separate schema language or remote catalog. It is editing structures that ultimately resolve back to generated tables, fields, indexes, and rules.[3]

The FAQ doubles down on that storage choice by saying PocketBase uses embedded SQLite in WAL mode and has no plans to support other databases out of the box.[2] This is a very strong boundary. Projects that want PostgreSQL, MySQL, horizontal failover, or a multi-node write topology are being told early that PocketBase is not interested in becoming a universal database facade.[2] The compensation is simplicity. SQLite plus one binary gives the system a small blast radius, easy local portability, and a deployment story that remains understandable to a single operator.

Auth collections show the same design instinct. They inherit the base collection model but add opinionated system fields such as email, verified, password, and tokenKey, plus their own auth-aware endpoints and rules.[3] The important point is that authentication is not an external service stitched on top of the data model. It is another collection type with specific security semantics and rule surfaces inside the same backend.[3]

Stateless auth keeps the server thin and the client honest

PocketBase's authentication docs are unusually explicit about state. The Web APIs are fully stateless, and an auth record is considered authenticated when the request carries a valid Authorization token.[4] There are no traditional server sessions in the middle. That architectural decision keeps the server surface small, but it also moves more responsibility to client and application design.

The docs show this plainly in the SDK examples. Clients authenticate, persist the returned token and record inside an authStore, and later clear or refresh them as needed.[4] Even more revealing is the note on authRefresh: a refresh call returns a new token and current user data, but previously issued tokens are not invalidated automatically and can be ignored if the client does not need the new one.[4] That is a thin, stateless contract. It is great for portability and easy edge deployment. It is less great if you want a large server-side session management system making revocation and long-lived web auth behavior opaque for you.

This is one of the cleanest examples of PocketBase's overall philosophy. Instead of hiding complexity in hosted infrastructure, it exposes a simpler primitive and expects the application to own the surrounding policy. The benefit is clarity. The cost is that teams must think through token storage, refresh cadence, multi-client logout expectations, and superuser boundaries rather than assuming an enterprise identity platform lives invisibly behind the scenes.[4]

Realtime stays lightweight because it rides ordinary HTTP patterns

PocketBase's realtime layer is powerful precisely because it does not try to become a giant stream-processing system. The homepage and SDK examples present realtime as collection subscriptions, while the "How to use" docs call out EventSource requirements for Node.js and React Native environments.[5][6] That tells you the feature is built around a relatively thin transport pattern rather than around a custom durable event bus with brokers, partitions, and replay semantics.

That thinness is a feature. When the FAQ claims the project can support large numbers of persistent realtime connections on modest hardware, the reason is not that PocketBase discovered a secret distributed-systems trick. The reason is that the project keeps the contract relatively small: record-level updates, collection subscriptions, and an application model already centered on one vertically scaled server.[2][5][6]

The limitations follow naturally. View collections do not emit realtime events because they do not own create, update, and delete operations.[3] Browser and mobile clients can subscribe easily, but deeper event-processing guarantees still belong to the application around PocketBase, not to PocketBase itself.[5][6] If you need ordered replay across services, independent consumers, or an audit-grade event log, you have stepped beyond the system it is trying to be.

Hooks are the escape hatch, not a serverless empire

The FAQ makes a subtle but important distinction: PocketBase does not offer cloud functions like Firebase or Supabase, but it can be used as a Go or JS framework for application-specific logic.[2] This is not just product positioning. It is the architectural answer to the question, "Where does custom behavior live?"

PocketBase's answer is: inside the same portable backend, through hooks and extensions, not inside a separate hosted runtime.[2][6] That is why the docs keep emphasizing "standalone app or framework" rather than "backend plus managed compute."[1][2][6] The project wants custom logic to stay close to the binary, the database, and the application deploy, even when that means giving up the convenience story of serverless add-ons.

This is where the LogRocket tutorial is useful as a secondary ecosystem read. It treats PocketBase as a fast way to assemble the common pieces of an MVP, especially auth, uploads, access rules, and realtime, rather than as a replacement for every category of backend infrastructure.[9] That outside reading matches the primary docs more than it contradicts them. PocketBase's real trick is not infinite extensibility. It is that the default extension path still preserves the project's small operational shape.[1][2][9]

The fit is narrower than the hype, and that is why it is credible

The best PocketBase teams are the ones that actively want its boundaries. They are happy with one server. They accept SQLite as the core store. They want auth, files, collections, and admin screens without operating separate services. They can tolerate pre-1.0 migration discipline. They do not need a hosted function platform to complete the picture.[1][2][3][4]

The weak fit is just as clear. If you need horizontal scale, a swappable database layer, guaranteed compatibility stability, or a thick enterprise identity and eventing story, PocketBase will either disappoint you or tempt you into building the missing platform around it.[1][2][4] At that point the one-file boundary stops saving effort and starts becoming the thing you are working around.

That is why the most accurate way to read PocketBase in 2026 is as a deliberately compressed architecture. Plain SQLite tables underpin collections, auth stays stateless, realtime remains lightweight, and custom logic enters through framework-style hooks rather than through a larger hosted ecosystem.[1][2][3][4][5][6] The project is persuasive not because it promises everything, but because it keeps refusing to promise what it cannot carry cleanly inside one binary.

cronfeed.work