PocketBase
An open-source Go backend that ships as one executable — SQLite with realtime subscriptions, users, file storage and an admin dashboard included
PocketBase is an MIT-licensed open-source backend that arrives as a single executable file. Inside it are an embedded SQLite database with realtime subscriptions, built-in user and authentication management, file storage, an admin dashboard and a REST-ish API — so a founder can have a working backend running locally in about a minute and deployed on one small server after that. You can use it as a finished app you configure, or import it as a Go library and build your own single portable binary around it. It carries 60,909 GitHub stars as of 2026-09-01, and its own README is clear that breaking changes are still expected before version 1.0.0.
What PocketBase actually is
Most backends are an assembly job: a database somewhere, an auth service beside it, an object store for uploads, a small admin panel you keep meaning to build, and the glue between them. PocketBase collapses that into one process and one file on disk. You download an executable for your platform, run it, open the dashboard in a browser, define your collections, and your app has an API — no container orchestration, no managed database, no separate auth vendor, and nothing to configure before the first request works.
The trade is visible and deliberate. Because the database is embedded rather than networked, the whole backend is one process holding one SQLite file, which is what makes it so simple to run and also what makes horizontal scaling a different conversation than it is elsewhere. For the stage most readers of this page are at — an app with no users yet, or a few hundred — that trade is heavily in your favour, and it stays that way much longer than people expect.
- An embedded database with realtime subscriptions. SQLite inside the binary, plus a subscription API so clients receive changes as they happen rather than polling for them. Live-updating UI is a default rather than a project.
- Users and files, built in. Authentication and user management ship with it, as does file handling, so the two features that usually pull in a third-party service on day one are already there.
- An admin dashboard and a REST-ish API. A web UI for defining collections, editing records and inspecting data, over an HTTP API that the official SDKs wrap. The JavaScript SDK covers browsers, Node.js and React Native; there is a Dart SDK for Flutter and desktop.
- One portable executable. The prebuilt binaries use a pure-Go SQLite driver and build with CGO disabled, so they cross-compile to a published list of Linux, macOS, Windows, FreeBSD, OpenBSD and NetBSD targets. Deployment is copying a file and running it.
Two ways to run it, and the choice matters later
The first way is as a standalone app. Download the release for your platform, extract it, run the serve command, and you are done. The prebuilt executables also carry a JavaScript VM, so you can add hooks and custom endpoints in JavaScript without touching Go or rebuilding anything. This is the path that gets a prototype in front of someone this afternoon, and it is a perfectly reasonable place to stay.
The second way is as a Go library. You import PocketBase into a Go program of your own, register routes and business logic against its lifecycle events, and compile the result — your code and the whole backend — into one statically linked executable. The README's own minimal example is about fifteen lines. The reason to know this on day one is that it is the escape hatch: the standalone app does not become a wall when your logic outgrows configuration, because the same project is also the framework underneath it. Requirements are modest, currently Go 1.27 or newer to build.
Where it fits a founder's growth stack
PocketBase is a build tool, not a growth tool, so its contribution to growth is indirect and worth naming honestly: it removes the weeks between having an idea and having something a stranger can sign into. That matters because almost nothing you can learn about demand is available before that point. What it does not do is bring anyone to the thing you built.
- For a first working version. Auth, storage and a database in one download is the shortest honest route from a prototype to something you can put a real login in front of. If you are building the front end with AI tooling, what is the best way to market a vibe-coded app picks up where the build stops.
- For internal tools you do not want to pay for. A waitlist, a content calendar, an outreach tracker, a lightweight CRM for your first fifty conversations. Collections plus the admin UI covers a surprising amount of this without becoming a product you have to maintain.
- Alongside, not instead of, the growth layer. Nothing here writes your positioning, publishes anything, or answers a customer. Once the product exists the work changes shape entirely — how do I get my first 100 users is the next problem, and it is a harder one.
- Know what you are adopting. It is MIT-licensed and the README explicitly permits commercial use, including selling a service built on it. It is also pre-1.0 with breaking changes expected, and the repository has pull requests temporarily restricted to existing collaborators because of a wave of low-quality automated submissions — so plan to file issues rather than patches.
What we learned running SQLite in production
We are not neutral here, and that is the useful part: AgentCeres runs SQLite in production too, so what follows is a decision we made rather than a review from outside. The single most important thing a one-file backend changes is that where the file lives becomes your entire architecture. Ours sat on a mounted volume, and the failure we kept meeting was that anything a container had written which nobody had pushed to durable storage simply did not survive the next deploy. It never announced itself as an error either — it presented as an app that had quietly forgotten something, which is the worst possible way for data loss to arrive.
The second surprise was that the volume itself was the scarce resource, not the disk space on it. Our host caps the number of volumes per project, and we hit that ceiling far earlier than any capacity limit, which eventually forced a re-architecture: containers became disposable and the durable state moved to a database plus object storage that outlive them. If you are running one PocketBase for one product this will never touch you. If you find yourself wanting one per customer, count the volumes before you design around them.
The third is SQLite-specific and cost us a genuinely confusing afternoon. SQLite's typing is flexible: we had stored timestamps as integers in some columns and as text in others, and comparisons across those two forms return no error at all — just the wrong rows, quietly, in a query that reads correctly. PocketBase manages its own schema, so you are largely insulated from this until you start writing your own queries or your own Go extensions against the same file, at which point it becomes yours. Decide your storage format once and check the column type before you trust a comparison.
FAQ
- Is PocketBase ready for production if it is still pre-1.0?
- People do run it in production, and its release cadence is steady — versions 0.40.0 and 0.40.1 landed on consecutive days in late August 2026, on top of a maintained older line. But take the README at its word rather than ours: full backward compatibility is not assured before 1.0.0, so upgrades between minor versions can require work. Read the changelog before you upgrade, pin your version, and treat that reading as part of the cost of the simplicity you are buying.
- Will SQLite handle my traffic?
- Almost certainly, for far longer than the question implies — a single file on a local disk removes network latency from every read, and read-heavy workloads on modest hardware go a very long way. The real constraint is shape rather than volume: writes serialise, and the whole thing is one process on one machine, so a workload that is write-saturated or that needs several application servers is asking for something else. Judge it against your actual write pattern, not against a headline number.
- Do I have to write Go to use it?
- No. Run the prebuilt executable and talk to it from your existing front end through the JavaScript SDK, which works in browsers, Node.js and React Native, or the Dart SDK for Flutter. The prebuilt binaries also embed a JavaScript VM for hooks and custom endpoints. Go only enters the picture if you choose the library route to compile your own logic into the same binary, and that decision can wait.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.