Short answer: in the PocketBase vs Supabase decision, you are choosing between a single file you run yourself and a managed Postgres platform someone else runs for you. PocketBase is one Go executable with an embedded SQLite database, auth, file storage, realtime and an admin dashboard. It costs whatever your server costs, often a few dollars a month. Supabase gives you a real Postgres database plus auth, storage, edge functions and realtime as a hosted service: free for small projects (with pausing), then $25/month per organization on Pro. Pick PocketBase for small, read-heavy apps, internal tools and prototypes where you are happy to own the server. Pick Supabase when you need Postgres features, heavy concurrent writes, a growth path, or simply don’t want to be the person who restores backups at 2 a.m.
Last updated: November 11, 2026. Pricing comes from supabase.com/pricing and railway.com/pricing, and PocketBase facts come from pocketbase.io (docs, FAQ, changelog for v0.42.0), all read on November 11, 2026. The PocketBase terminal output below is from a real run of v0.42.0 on my Linux box the same day. Forum notes are paraphrased from Reddit and Hacker News threads.
PocketBase vs Supabase at a glance
| PocketBase | Supabase | |
|---|---|---|
| What it is | One self-hosted executable (Go + embedded SQLite) | Hosted platform around a dedicated Postgres database |
| Database | SQLite in WAL mode | PostgreSQL with extensions |
| Hosting | You host it (VPS, Railway, Fly.io, a home server) | Supabase hosts it (self-hosting possible via Docker) |
| Price to start | $0 software + your server | $0 Free plan (2 active projects, paused after 1 week idle) |
| Typical paid cost | A small VPS or roughly the $5 Railway Hobby plan | $25/month Pro, plus compute for each extra project |
| Auth | Email/password, OTP, MFA, 15+ OAuth2 providers | Email, phone, OAuth, anonymous, MFA, SSO add-ons |
| Access control | Per-collection API rules | Postgres Row Level Security (RLS) policies |
| Server code | JS hooks or use it as a Go framework | Edge Functions, database functions, triggers |
| Scaling | Vertical only (one server) | Compute add-ons from shared Micro up to dedicated 64 vCPU |
| Maturity | Pre-1.0, breaking changes possible | Large company, big ecosystem |
The table makes it look like Supabase wins on everything except price. It doesn’t. The real difference is who carries the operational risk, and PocketBase’s whole pitch is that there is very little operation to carry.
What PocketBase actually is (and what I saw running it)
PocketBase is a personal open-source project by one developer. The binary is about 12 MB zipped, and you start it with ./pocketbase serve. It creates a pb_data folder for the database and uploads and a pb_migrations folder for schema changes you can commit to Git.
To keep this post honest, I downloaded v0.42.0 on my Linux box this morning, created a todos collection through a JS migration, signed up a test user and wrote one record. Here is the relevant output:
$ ./pocketbase --version
pocketbase version 0.42.0
$ ./pocketbase serve --http=127.0.0.1:8090
Server started at http://127.0.0.1:8090
> Dashboard: http://127.0.0.1:8090/_/
> REST API: http://127.0.0.1:8090/api/
$ curl -s http://127.0.0.1:8090/api/health
{"message":"API is healthy.","code":200,"data":{}}
# anonymous request to the todos collection (API rules require a logged-in owner)
$ curl -s http://127.0.0.1:8090/api/collections/todos/records
{"items":[],"page":1,"perPage":30,"totalItems":0,"totalPages":0}
# same request with the owner's auth token
totalItems 1 ['Ship the landing page']
$ du -sh pb_data
1.2M pb_data
$ ps -o rss= -p <pocketbase pid>
34160So on that box the whole backend sat at roughly 34 MB of resident memory with one user and one record, and the data folder was 1.2 MB. That is a toy workload, not a benchmark, but it shows why people call PocketBase “dumb easy”: there is nothing else to install.
Two details from that run matter for vibe coders:
- An anonymous list returns an empty list, not an error. If your API rule is wrong, your frontend may just show “no data” instead of failing loudly. Always test with a logged-out request and a second user.
- Version 0.41 moved PocketBase off GitHub. Downloads and the Go module now live on the author’s own host (
ganigeorgiev.com), and the GitHub releases page stops at v0.40.6. Older tutorials, Dockerfiles and AI-generated scripts still point at GitHub URLs, so update them.
Here is the migration file I used. It is a good starting point to paste into your own pb_migrations folder:
/// <reference path="../pb_data/types.d.ts" />
migrate((app) => {
const todos = new Collection({
type: "base",
name: "todos",
listRule: "@request.auth.id != '' && owner = @request.auth.id",
viewRule: "@request.auth.id != '' && owner = @request.auth.id",
createRule: "@request.auth.id != '' && @request.body.owner = @request.auth.id",
updateRule: "owner = @request.auth.id",
deleteRule: "owner = @request.auth.id",
fields: [
{ type: "text", name: "title", required: true, max: 200 },
{ type: "bool", name: "done" },
{ type: "relation", name: "owner", required: true, maxSelect: 1, collectionId: "_pb_users_auth_" },
{ type: "autodate", name: "created", onCreate: true },
],
});
app.save(todos);
}, (app) => {
app.delete(app.findCollectionByNameOrId("todos"));
});What Supabase gives you that PocketBase doesn’t
Supabase is a dedicated Postgres database with a set of services around it. That one fact explains most of the comparison:
- Real SQL. Joins, views, window functions, triggers, and extensions like pgvector for AI search. If your app has reporting, analytics or anything beyond simple CRUD, Postgres is the safer bet.
- Concurrent writes. SQLite allows one writer at a time. PocketBase queues writes and uses WAL mode so reads keep going, and for most small apps you won’t notice. Chat, telemetry, multiplayer or bulk imports are where people report trouble.
- Managed backups and no server. Pro includes daily backups kept for 7 days, and there is nothing to patch.
- A big ecosystem. Official SDKs, lots of tutorials, and AI coding agents that already know the Supabase client well.
The flip side: Supabase’s access control lives in RLS policies, and a missing policy is one of the most common holes in AI-built apps. My vibe-coded app security checklist covers that in detail.
PocketBase vs Supabase pricing (November 2026)
Supabase (from supabase.com/pricing, November 11, 2026):
| Plan | Price | What matters for a solo founder |
|---|---|---|
| Free | $0 | 500 MB database, 1 GB file storage, 5 GB egress, 50,000 MAU, 2 active projects, paused after 1 week of inactivity, no automatic backups |
| Pro | from $25/month | 8 GB disk per project, 100 GB storage, 250 GB egress, 100,000 MAU, daily backups (7 days), spend cap on by default |
| Extra projects | about $10/month each | Each project runs on its own compute; Pro’s $10 credit covers one Micro instance |
Supabase’s own example: a Pro organization with two Micro projects costs $25 + $10 + $10 minus the $10 credit, so $35/month. If you run several side projects, that per-project compute adds up faster than the plan fee. I broke this down further in Supabase pricing for solo founders.
PocketBase is free software, so you pay for the machine:
- A small VPS. The PocketBase FAQ says a $4 Hetzner CAX11 (2 vCPU, 4 GB RAM) can serve 10,000+ persistent realtime connections. Treat that as the author’s claim and check the provider’s current price.
- Free cloud tiers. The FAQ lists Google Cloud’s e2-micro free tier and Oracle Cloud Always Free for proofs of concept.
- Railway. See the next section.
For a typical MVP with a few hundred users, the honest cost gap is roughly $5 versus $25 a month. That is real money when you have no revenue, but it is not life-changing, so let the technical fit decide first.
Railway vs Supabase: a different kind of comparison
People search “railway vs supabase” because both show up in cheap-stack lists, but they solve different problems. Railway is a hosting platform that runs your containers and databases and bills per second for CPU, memory and disk. Supabase is a backend platform with auth, storage and APIs built in.
That makes Railway a natural home for PocketBase, or for a plain Postgres database next to your own API. Railway’s pricing on November 11, 2026:
| Plan | Fee | Included usage | Limits that matter |
|---|---|---|---|
| Free | $0 | $1/month | 0.5 GB RAM per service, 500 MB volume, no custom domain |
| Hobby | $5/month | $5/month | 5 GB max volume, 2 custom domains |
| Pro | $20/month | $20/month | 1000 GB volumes, 20 custom domains |
Usage is about $10 per GB of memory per month, $20 per vCPU per month and $0.15 per GB of volume per month. My rough math, not a quote: PocketBase idling near 34 MB of RAM with a 1 GB volume would use well under a dollar of resources a month, so a small app should fit inside the Hobby plan’s included $5. Real CPU use under traffic will push that up, so watch the usage page for the first month.
The one rule for PocketBase on any container host: **mount a persistent volume at the pb_data path.** Without it, every redeploy wipes your database. The official Dockerfile example in the PocketBase docs expects a volume at /pb/pb_data.
Which one should you pick?
Use this as a quick decision list:
- Do you need Postgres features (complex queries, pgvector, reporting)? Pick Supabase.
- Will many users write at the same moment (chat, live collaboration, event tracking)? Pick Supabase, or load test PocketBase first.
- Is it an internal tool, a small SaaS, a mobile app backend or a prototype? PocketBase is a great fit.
- Do you want zero servers to look after? Pick Supabase.
- Do you run five side projects and hate per-project fees? Several PocketBase instances on one small VPS is hard to beat on cost.
- Are you a non-developer relying entirely on an AI agent? Read the next section first.
The AI-agent warning nobody mentions
The PocketBase FAQ says plainly that it is a volunteer project with no promises of maintenance, and that if you don’t have time to at least skim the docs and plan to rely only on an AI tool, you should not use PocketBase. That is unusually blunt, and I think it is fair.
In practice, the trap looks like this: your agent writes code for an old PocketBase version (the JS hooks and Go APIs changed a lot around v0.23), the code half-works, and you can’t tell which half. Supabase has the opposite problem: agents know it well, but they love to skip RLS.
If you use an agent with either backend, pin the version and paste the rules into your project instructions. For example, in your CLAUDE.md or AGENTS.md:
## Backend rules
- Backend: PocketBase v0.42.0 (single binary). Docs: https://pocketbase.io/docs/
- Schema changes go in pb_migrations/*.js only. Never edit pb_data by hand.
- Every collection needs explicit list/view/create/update/delete rules.
Default to owner-only: owner = @request.auth.id
- After any rule change, test: logged out, as user A, and as user B.
- Do not use APIs from before v0.23 (old hooks syntax). If unsure, say so and link the doc page.For Supabase, swap in: “Every table in the public schema must have RLS enabled with at least one policy; never ship the service_role key to the browser.”
Alternative to Supabase: when PocketBase isn’t the answer either
If you’re looking for an alternative to Supabase for cost or lock-in reasons, PocketBase is one option, but not the only one:
- Firebase if you want Google’s managed stack and are fine with NoSQL. I compared them in Supabase vs Firebase.
- Plain managed Postgres plus your own auth library if you mainly want “Postgres and a client” without a platform wrapper.
- Self-hosted Supabase with the official Docker setup, if you want the Supabase feature set on your own server. Expect a stack of many containers and more RAM, which is the opposite of PocketBase’s footprint.
Forum consensus in 2026 is fairly consistent: PocketBase for zero-ops prototypes and small apps, Supabase when the data model gets serious.
Migrating later: plan the escape hatch now
The biggest worry in PocketBase threads is getting stuck on one server with one SQLite file. PocketBase’s FAQ admits there are no built-in import/export helpers yet. Lower that risk from day one:
- Back up from the start. The dashboard has backups under Settings > Backups, locally or to S3-compatible storage. Through the API, my test backup of a fresh instance was a 228 KB zip. For larger data (the docs mention 5 GB+), use
sqlite3 .backupplus rsync, or Litestream for continuous replication. - Keep business logic in your app, not in hooks, so moving to Postgres later means rewriting a data layer, not the whole product.
- Use plain field types (text, number, bool, relations) that map cleanly to Postgres columns.
Going the other way, from Supabase to PocketBase, is rarer and harder, because you lose SQL features you may already rely on.
Pitfalls I’d watch for
- PocketBase is pre-1.0. The docs say it is not recommended for production-critical apps yet unless you’re fine reading the changelog and doing occasional manual migration steps.
- Email defaults. PocketBase uses the system
sendmailby default. Set up an SMTP provider before launch or your verification emails will land in spam. - Superuser exposure. Turn on the rate limiter and restrict superuser access to your IPs (Settings > Application), both recommended in the production guide.
- Supabase free pausing. Free projects pause after a week without activity. Fine for demos, bad for a live product with quiet weeks.
- Supabase per-project compute. Each extra project adds compute cost on Pro. Count your projects before you assume $25 is the total.
My take
For most readers of this blog, people shipping a first SaaS with an AI coding agent, I’d still start with Supabase, mainly because agents know it well, backups are handled, and Postgres won’t box you in. I’d switch to PocketBase for internal tools, client dashboards, small mobile backends and the pile of side projects where a $25 plan each would be silly. And if you pick PocketBase, read its docs yourself, even if an agent writes the code. The project’s own FAQ asks you to, and it’s right.
If you’re still choosing the rest of the stack, my real monthly cost of an AI indie dev stack and Vercel vs Netlify posts cover the pieces around the backend, and running sessions over SSH helps if you put PocketBase on a VPS and want your agent working on that box.
FAQ
Is PocketBase better than Supabase?
Neither is better overall. PocketBase is simpler and cheaper to run for small, read-heavy apps on one server. Supabase is stronger for complex data, concurrent writes and teams that don’t want to manage servers.
Can PocketBase use Postgres?
No. PocketBase uses embedded SQLite in WAL mode, and its FAQ says there are no plans to support other databases.
Is PocketBase free?
Yes, it’s open source (MIT). You only pay for the server or hosting platform you run it on.
Does Supabase have a free plan in 2026?
Yes. The Free plan includes a 500 MB database, 1 GB of file storage and 50,000 monthly active users across up to 2 active projects, but free projects pause after one week of inactivity.
Can I host PocketBase on Railway?
Yes. It runs fine in a container, as long as you attach a persistent volume for the pb_data folder. A small app should fit inside the $5 Hobby plan’s included usage, but check your usage page.
Does PocketBase scale?
Only vertically, on a single server. The FAQ positions it for small and mid-size apps. If you expect heavy write traffic or need replicas, choose Postgres.