Supabase vs PocketBase - Postgres Platform or One-File Backend

Supabase vs PocketBase is mostly a question of how much infrastructure you want. PocketBase is a single executable with an embedded SQLite database, auth, file storage, realtime and an admin UI: download it, run it on a $5 server, done. Supabase is a hosted Postgres platform with the same building blocks plus SQL, row level security, extensions, backups and scaling options. Pick PocketBase for small apps, prototypes and internal tools you're happy to run yourself. Pick Supabase (or another hosted Postgres backend) when the app needs to grow, needs more than one writer at scale, or nobody wants to be on call for the server.

#What each one is

PocketBase describes itself as an "open source backend in 1 file". Its docs say it consists of an embedded SQLite database with realtime subscriptions, built-in auth management, a dashboard UI and a REST-ish API. You can use it as a standalone app or as a Go framework, and extend it with Go or JavaScript hooks. Files can be stored locally or in S3. The current release shown on its site is v0.41.1.

Supabase is a hosted platform (also self-hostable with Docker) around Postgres: auto-generated REST and GraphQL APIs, Auth, Storage, Realtime, Edge Functions, and a dashboard. Each project is a full Postgres database.

#Side-by-side

#The maturity question

PocketBase's docs are refreshingly honest: "PocketBase is still under active development and full backward compatibility is not guaranteed before reaching v1.0.0," and it's "NOT recommended for production critical applications yet, unless you are fine with reading the changelog and applying some manual migration steps from time to time."

That doesn't mean you can't ship on it. Many people do. It means upgrades are your job, and you should pin versions and read release notes. Supabase is a company-run platform where upgrades happen for you.

#Scaling: one server vs a platform

SQLite is fast. On a single machine with a local SSD, reads are microseconds away, and a small app will never notice the database. The limits show up in two places:

• Writes. SQLite serializes writes per database file. For most apps that's fine up to a surprising volume; for write-heavy workloads with many concurrent users, Postgres handles concurrency better.
• One machine. PocketBase runs in one process on one server. To scale, you buy a bigger server. There's no built-in read replica or failover; if the machine dies, you restore from your backup.

Supabase separates the database from your app and offers larger compute sizes and read replicas. You trade simplicity for headroom.

#Access rules vs Row Level Security

PocketBase API rules are filter expressions on each collection. A "users see only their own notes" rule looks like:

@request.auth.id != "" && owner = @request.auth.id

In Supabase you write the same intent as a Postgres policy:

alter table public.notes enable row level security;

create policy "Owners read their notes" on public.notes
  for select to authenticated
  using (owner_id = auth.uid());

PocketBase rules are quicker to write for simple cases. Postgres policies are more powerful when a rule depends on other tables, roles or JWT claims, and they also protect the data when you connect with other tools. A policy that checks team membership, for example, is one exists (...) subquery; in a PocketBase rule you would express it through relation fields on the collection. See row level security for policy patterns that work the same on Supabase and StitchDB.

#Extending with code

PocketBase shines here for Go developers. You import it as a library, add routes and hooks, and ship one binary that contains your whole backend. JavaScript hooks give the same without compiling.

Supabase splits server code across Edge Functions (TypeScript on Deno), Postgres functions callable over REST, and triggers. More pieces, but each scales independently and you don't redeploy the database to change a function.

#Costs

PocketBase itself is free. You pay for a server, backups storage and your time. A small VPS can run many small apps.

Supabase, as of November 2026: Free has 500 MB database, 1 GB storage, 50,000 MAU and 2 active projects, paused after a week without activity. Pro starts at $25/month and includes $10 of compute credits (Supabase pricing).

#Where StitchDB fits

If you like PocketBase's "everything in one place" feel but don't want to run a server, StitchDB is a hosted option in the Supabase-compatible family: a dedicated Postgres database per project, with Auth, REST and GraphQL APIs, Realtime, Storage and Edge Functions, plus app services such as cron, queues, push notifications and feature flags. Supabase client libraries work with it by changing the URL and keys.

Things PocketBase users usually care about:

• Local development without Docker. stitchdb start runs Postgres, Auth, REST, Realtime, Storage, Edge Functions and a local Studio as plain processes on your machine (local development). The first start downloads about 40 MB once.
• Free tier that doesn't pause while you use the account: 2 projects with 500 MB of database each.
• Backups you don't manage: point-in-time recovery on every plan (24 hours on Free, 7 days on Pro at $15.99/month; see pricing).

The honest downsides compared with PocketBase: you can't drop it on your own VPS (no self-hosted edition), data lives in EU data centers only, and it costs money once you outgrow Free. For an internal tool on your own server, PocketBase is simpler.

#Who should pick what

• PocketBase: prototypes, hackathons, side projects, internal tools, apps that fit on one server, Go developers who want a backend framework, and anyone who wants zero vendor dependency.
• Supabase: production apps that need Postgres, growth room, managed backups, regions worldwide and a team that doesn't want to run servers.
• StitchDB: the same Postgres-backend model as Supabase, hosted in the EU, with a no-pause free tier and Docker-free local development.

If you're comparing more options, see PocketBase alternatives and Supabase vs Firebase.

#Moving from PocketBase to Postgres later

It's common to start on PocketBase and move. Plan for it:

1. Keep ids as text or uuid so they survive the move.
2. Export collections to JSON or CSV (or read the SQLite file directly with sqlite3).
3. Create matching tables in Postgres, converting PocketBase's JSON fields to jsonb and relation fields to foreign keys.
4. Translate each API rule into a policy.
5. Users: PocketBase stores password hashes in its own format; plan a password reset or magic-link sign-in unless your target can verify them.

#FAQ

#Is PocketBase production ready?

Its own docs say it's not recommended for production-critical apps before v1.0 unless you're fine following the changelog and doing manual migration steps. Many smaller apps run it in production anyway.

#Can PocketBase scale like Supabase?

It scales up on one server, not out. Supabase offers bigger compute and read replicas.

#Is PocketBase free?

Yes, it's open source. You pay for the server you run it on.

#Does Supabase use SQLite?

No. Supabase is built on Postgres.

Want PocketBase-level simplicity without running a server? Start free on StitchDB.