PocketBase vs Supabase for a Solo App: Which Backend You Can Keep in One Head

Supabase is a Postgres company that also gives you auth, storage, and a dashboard that feels like a product. PocketBase is a single binary that gives you auth, files, and an admin UI that feels like a tool. For a solo app, the question is not which logo is more employable. It is which stack you can keep in one head when something is on fire on a Tuesday.

I have shipped a side project on each. The Supabase one still exists and I still open the dashboard with a slight flinch. The PocketBase one lives on a $6 box and I can explain every moving part before the kettle boils. That is the test. If you cannot explain the moving parts, you do not have a backend. You have a bill and a faith.

What you are actually operating

Supabase hosted is a region, a project, a set of keys, migrations, RLS policies, edge functions if you got ambitious, and a storage bucket that has its own story. Self-hosting Supabase is a compose file that looks like a small company. I have looked at that compose file and closed it. I am one person.

PocketBase is a binary, a data directory, and a reverse proxy if you are not a monster. SQLite under the hood. Realtime if you want it. Auth that is good enough for a small user list. Files on disk. You will think about backups of one folder. You will not think about sixteen containers agreeing.

If your app is a multiplayer product with a team and a compliance checklist, stop reading and use Postgres. This article is for the person who will be paged by themselves.

Auth, RLS, and the policy you will get wrong

Supabase’s row level security is the grown-up feature and the Tuesday fire. A policy that is slightly wrong leaks a row or hides a row. Both look like “the app is broken.” I have shipped a policy that used the wrong uid claim and spent an evening blaming the client. The dashboard will not save you from a boolean you inverted. It will let you write the boolean faster.

PocketBase rules are simpler and less famous. You can still leak. You have less surface. I can read the collection rules in one screen. I cannot always read an RLS stack in one screen after a month of “just one more policy.” For a solo CRUD app with a few roles, simpler rules that I will actually review are safer than a Postgres textbook I will not reread.

If you need Postgres extensions, GIS, serious reporting, or five other services reading the same DB, Supabase (or raw Postgres) wins and PocketBase is a toy. Call it a toy before you pretend otherwise.

Backups you will actually restore

I have restored a PocketBase data directory from a nightly copy. It was a folder. I have restored a Supabase project from a backup I hoped was current. It was fine. It was not a folder I could hold. Hosted backups are a product. They are also a relationship. If the relationship is the only copy, you have a vendor as a brain.

For PocketBase I copy the directory and I test-open it on another machine once a month. For Supabase I export the bits I cannot lose and I do not pretend the dashboard snapshot is a philosophy. Both need a drill. The drill that is a folder is the one I will do when I am tired.

Local-first and the airplane test

PocketBase on a laptop for a demo is a party trick that is also a workflow. You can develop without an account. Supabase local is better than it was and still a stack. I have lost an afternoon to Docker Desktop for a form that needed email login. If your joy is shipping UI, the binary wins the afternoon.

Production is different. A binary on a VPS is a process you must keep up. Supabase hosted is a process they keep up until your card fails. I keep PocketBase behind Caddy and Tailscale for admin. I keep a healthcheck on the process. I do not expose the admin UI to the world. The same rule as n8n. Editors are not public.

When the app stops being solo in your head

A second developer will ask for staging. Supabase branches and previews feel like a team. PocketBase staging is a second binary and a second directory you must remember. I can remember two directories. I start to forget four. If you are about to hire, the hosted Postgres story is kinder. If you are not about to hire, do not hire a platform in advance.

Migrations: Supabase wants you to be a grown Postgres person. PocketBase collections change in the UI and you can export schema. I still write down what I changed. UI migrations without a note are how Tuesday happens. Git is allowed to hold a schema dump for either.

Realtime, files, and the extra logo

Both will do files. Supabase storage plus a CDN story is nicer at scale. PocketBase files on a small disk are nicer at 2 GB. I have filled a disk with user uploads because I did not cap them. That is not a brand problem. That is a missing max-size. Set the max-size before you tweet the launch.

Realtime is a reason people pick either. For “this row changed,” both can work. For a game lobby, you wanted a different article. I use realtime for a presence dot and I do not build a chat on a solo backend I have not load-tested. Load I have not seen is a fantasy.

Cost that is not just dollars

Supabase free tier is generous until it is a pause or a limit you hit on a launch day. PocketBase is cheap until you are the SRE. I price my hours. If I will not SSH, I pay Supabase. If I already SSH for the rest of the homelab, PocketBase is a neighbor. Neighbors can be down when the power is down. Hosted can be down when their region is down. Pick the outage you understand.

Email, magic links, and the vendor you still have

Neither product sends mail by itself in a way that makes deliverability go away. You will still have SMTP, a provider, and a bounce story. PocketBase does not erase that. Supabase Auth does not erase that. I budget an email vendor even for the “tiny” app. Users who cannot log in do not care that your database is a single binary.

OAuth buttons are a Tuesday of callback URLs. I add one provider I will actually test. I do not add five because the dashboard offers five. Each provider is a secret I must rotate when a contractor leaves — even if the contractor was me on a second laptop.

Rate limits on auth are how you avoid being a spam cannon. Set them. I have watched a leaked anon key become a signup flood. The flood is not a reason to pick the other logo. It is a reason to treat the anon key as public and the service role as a weapon. PocketBase admin and Supabase service role both open the house. They do not live in the frontend. I have seen both mistakes in starter templates. Delete them from the template before you commit.

Indexes, reports, and the query you will write twice

SQLite will take you farther than people who learned databases from Twitter think. It will not take you through a reporting week where three other tools need the same numbers at the same time. I have written a PocketBase view that was really a habit of exporting CSV. That habit is fine until a customer asks for a dashboard. Then you are either adding another process or you are migrating.

Supabase lets you write the ugly SQL and keep it. That is the whole pitch in one sentence. I still write the ugly SQL down in a file. The dashboard SQL editor is a scratch pad, not a museum. I have lost a useful query because I closed the tab. That is not a Postgres problem. That is a person problem with a nicer editor.

If you already think in joins, start where the joins live. If you think in collections and a small admin, start where the admin is one screen. Switching later is possible. Switching later while users exist is a project. I would rather pick the one that matches the first six months than pick the logo that matches a conference talk.

The backend I can keep in one head

For a new solo app with a few users and a folder of files, I would start PocketBase and I would write the restore drill on day one. For an app that already smells like SQL reports, other writers, or a future team, I would start Supabase and I would write the RLS down as if a stranger had to audit it next month — because next-month me is a stranger.

I would not run both. Two backends is two heads. One head is the product. The other is a weekend you will not get back. Keep the one you can explain before the kettle boils. If you cannot explain it, it is already too big, no matter how pretty the dashboard was on the landing page.