0 Get started
Two products that both chose SQLite and both refuse to hold your data, arriving there from opposite directions. PocketBase is a single executable you run. Pithy is a set of packages that assemble a Worker. If you like one of them for its instincts, you will probably like the other.
Choose PocketBase
When one binary on one box is genuinely enough.
Download an executable, run it, and you have a database, auth, file storage, realtime subscriptions and an admin dashboard. For a side project, an internal tool or a prototype, that is a remarkable amount of backend for no operational surface at all — and the admin UI is better than anything the kit offers.
Choose Pithy
When it has to run in production, near everyone.
Its own documentation says PocketBase is not recommended for production-critical applications before v1.0.0, and full backward compatibility is not guaranteed until then. A Worker runs in Cloudflare's network with no box to size, and the capabilities above it — payments, games, secrets, audit — are the part you were going to write anyway.
Where they overlap
If a feature is standard for a modern backend, assume both have it. We are not going to dress one up as a differentiator.
Both chose it, and for the same reasons. Neither should claim it against the other.
Sessions, OAuth providers, tokens. Both have it.
Upload, serve, authorize. Both have it.
Both, genuinely.
PocketBase is local by nature; Pithy runs the whole stack on Miniflare.
Neither product puts a service of its own between your user and your data.
The difference underneath
PocketBase is a process. It holds its data in a directory on disk beside the executable, which is what makes it so easy to run and what decides everything else about it: one machine, one disk, one place your users are close to.
Pithy assembles a Worker. D1 is SQLite too, but it is Cloudflare's SQLite — provisioned per environment, replicated by them, reachable from a runtime that already exists in every region. There is no box to size, back up or be woken by.
The honest framing is that these are not competitors so much as the same taste at two different scales. PocketBase is the better answer for one developer and one box. The kit is the answer when the thing has to survive being popular.
Feature by feature
| Feature | PocketBase | Pithy |
|---|---|---|
Runtime & data | ||
| SQLite PocketBase: embedded, in a directory beside the binary Pithy: D1, provisioned per environment in your Cloudflare account | Yes | Yes |
| Realtime subscriptions PocketBase: built in Pithy: Durable Objects for authoritative state; no table subscription | Yes | Partial |
| Admin dashboard for your data PocketBase: excellent, and included Pithy: the dashboard reads your data through a seam you grant; there is no table editor | Yes | Partial |
| Panes for users, money and the trail PocketBase: collections and a users collection, in the same admin UI Pithy: users, entitlements, purchases, subscriptions, support and the trail — and a user can be comped, revoked or signed out everywhere | Partial | Yes |
| Runs in every region PocketBase: one process on one machine Pithy: a Worker, in Cloudflare's network by construction | No | Yes |
| Horizontal scaling PocketBase: a single-node design Pithy: Workers scale because that is what they do | No | Yes |
Operations | ||
| No servers to run PocketBase: one, which is the whole point Pithy: there is no Pithy server to deploy | No | Yes |
| No backups to run yourself PocketBase: a directory you copy Pithy: Cloudflare's problem, per environment | No | Yes |
| Production-ready by its own account PocketBase: the docs say not recommended for production-critical apps before v1.0.0 Pithy: the primitives are Cloudflare's, generally available | No | Yes |
| Migrations PocketBase: schema migrations in `pb_migrations` Pithy: one ordered registry per database, with tested rollbacks | Yes | Yes |
What the kit adds | ||
| Payments on five rails, one entitlement Pithy: Apple, Google, Stripe, Paddle and Lemon Squeezy | No | Yes |
| Per-user balance ledger Pithy: atomic, idempotent, overdraft-safe by CHECK constraint | No | Yes |
| Games infrastructure Pithy: authoritative sessions, matchmaking, rating and leaderboards | No | Yes |
| Audit trail attributed to an actor Pithy: a queryable trail, including when a dashboard is the actor | No | Yes |
| Encrypted secrets with rotation Pithy: a registry, per environment, with at-rest rotation | No | Yes |
| Durable multi-step workflows Pithy: Cloudflare Workflows, used by the capabilities that need them | No | Yes |
The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about PocketBase was checked against their own documentation on 2026-08-25; both products change, and this page is a snapshot rather than a maintained contract.
Where Pithy pulls ahead
One process on one disk is the design, not a limitation to work around. A Worker has no box to outgrow, and D1 is provisioned rather than parked next to the binary.
PocketBase states plainly that it is not recommended for production-critical applications before v1.0.0, and that backward compatibility is not guaranteed until then. That is admirable honesty, and it is also a decision you have to make.
Payments across five rails on one entitlement, a ledger that cannot double-spend, matchmaking and authoritative sessions, and a trail attributed to the actor. None of that is in a single-binary backend, nor should it be.
dev, staging and prod are provisioned separately, and a branch can have its own ephemeral set. With PocketBase, a second environment is a second process and a second directory.
The data directory is the thing you must not lose. Cloudflare holds D1 and R2, per environment, without you owning a backup schedule.
Where PocketBase wins
A dashboard over your own collections, included, with no setup. The kit has nothing like it and does not try.
A single binary on a Raspberry Pi, a VPS or a laptop. No account with anyone, and no internet required.
Download, run, done. The kit asks you to understand capabilities, bindings, migrations and environments before the first request.
Subscriptions over your collections, out of the box. Durable Objects are more powerful and considerably more work.
No account, no usage bill, no tier. A Worker is cheap and it is not nothing.
If you write Go, PocketBase is a library as much as a binary. The kit is TypeScript and only TypeScript.
For a prototype, an internal tool or a project with one developer and one box, PocketBase is an excellent choice and adopting a kit instead would be over-engineering. The moment the thing has to be near users in more than one place, survive a machine dying, or take money — that is where a single process stops being the right shape, and it is the only claim this page is making.