PocketBase vs Supabase for Indie Developers (2026)

PocketBase is a single executable with an embedded SQLite database, auth, files, realtime and an admin dashboard, which you run on your own server. Supabase is a hosted Postgres platform with a free tier and a Pro plan from $25/mo. PocketBase wins on cost and simplicity for small apps you are happy to operate; Supabase wins when you want managed Postgres, managed backups and room to grow.

Editorial title card reading "PocketBase vs Supabase for Indie Developers (2026)" beside the orange ZeroRaised mark.

Key takeaways

  • PocketBase (v0.42.2 on its docs today) is one executable with embedded SQLite; its docs say it is 'NOT recommended for production critical applications yet' and backward compatibility is not guaranteed before v1.0.0.
  • Supabase Free gives 500 MB of database, 1 GB of file storage and 50,000 MAUs, but free projects are paused after 1 week of inactivity and you get 2 active projects. Pro starts at $25/mo.
  • PocketBase scales only vertically, on one server. Its FAQ says it can serve 10,000+ persistent realtime connections on a $4 Hetzner VPS.
  • Access control: PocketBase uses five per-collection API rules written as filters; Supabase uses Postgres Row Level Security policies, which must be enabled on every exposed table.
  • Our pick: PocketBase for side projects, internal tools and small single-region apps you will operate yourself; Supabase for SaaS that needs Postgres, managed backups and no server to babysit.
On this page 25
  1. TL;DR
  2. How this fits with our other backend comparisons
  3. PocketBase vs Supabase at a glance
  4. Architecture: one binary vs a Postgres platform
  5. The pre-1.0 warning, verbatim
  6. Auth
  7. API rules vs Row Level Security
  8. Realtime
  9. File storage
  10. Extending: Go and JS hooks vs Edge Functions
  11. Backups
  12. Scaling limits
  13. Cost: Supabase plans vs PocketBase on a VPS
  14. Self-hosting Supabase instead
  15. Migration path: PocketBase to Postgres
  16. Decision table by app type
  17. Our pick by situation
  18. Frequently asked questions
  19. Is PocketBase production ready?
  20. Is PocketBase cheaper than Supabase?
  21. Can PocketBase scale?
  22. Can I move from PocketBase to Postgres or Supabase later?
  23. Can I self-host Supabase instead of PocketBase?
  24. Ship it, then launch it
  25. Sources

Verdict: Pick PocketBase if you want the cheapest, simplest backend for a small app and you are comfortable running one server yourself: it is a single executable with SQLite, auth, files and realtime built in. Pick Supabase if you want managed Postgres, managed backups and no server to look after, and can live with the free tier pausing idle projects or pay $25/mo for Pro.

Every version, price and limit below comes from PocketBase's and Supabase's own pages (plus DigitalOcean and Hetzner for server prices), checked on 15 Nov 2026. The advice is ours and is marked as such.

TL;DR#

  • Architecture. PocketBase is one executable file with an embedded SQLite database (PocketBase docs). Supabase is hosted Postgres plus Auth, Storage, Realtime and Edge Functions (Supabase on GitHub).
  • Maturity. PocketBase is at v0.42.2 and says it is "NOT recommended for production critical applications yet" (PocketBase docs).
  • Cost. PocketBase is free MIT software on a server you rent, for example a $6/mo DigitalOcean Droplet (DigitalOcean). Supabase is $0 on Free, from $25/mo on Pro (Supabase pricing).
  • Scaling. PocketBase scales "Only on a single server, aka. vertical" (PocketBase FAQ). Supabase is a managed platform with paid compute upgrades.
  • Security model. PocketBase API rules per collection vs Supabase Postgres Row Level Security.

Disclosure: ZeroRaised publishes this comparison and is a launch site for bootstrapped products. ZeroRaised has no commercial relationship with PocketBase, Supabase, DigitalOcean or Hetzner and earns nothing if you use them. Facts come from the linked sources as checked on 15 Nov 2026.

How this fits with our other backend comparisons#

We have already compared Supabase with Firebase, Convex and Neon, and lined up free tiers across vendors in our free database hosting guide. Those posts cover the managed side well. This one is about a different question: should a solo developer skip the platform entirely and run one small binary on a VPS? If you have not picked a server yet, see our best VPS for indie hackers guide; we do not redo that choice here.

PocketBase vs Supabase at a glance#

PocketBaseSupabase
What it isOne executable: SQLite, auth, files, realtime, admin dashboard, REST-style APIHosted platform: Postgres, Auth, Storage, Realtime, Edge Functions
DatabaseEmbedded SQLite in WAL mode, no other databases plannedPostgres
Where it runsYour server (or used as a Go/JS framework)Supabase cloud, or self-hosted via Docker Compose
Current versionv0.42.2, pre-1.0Managed platform (no single version to track)
LicenceMITApache-2.0
Access controlFive API rules per collection (filter expressions)Postgres Row Level Security policies
RealtimeServer-Sent Events, record and collection subscriptionsBroadcast, Presence, Postgres Changes
FilesLocal pb_data/storage or S3-compatibleStorage API over S3, permissions in Postgres
Custom logicGo framework or JS hooks in pb_hooksEdge Functions (Deno, TypeScript) plus Postgres functions
BackupsBuilt-in ZIP snapshots, local or S3Pro: 7 days; Team: 14 days; Free: none
ScalingVertical only, one serverManaged; upgrade compute
Cheapest always-on optionYour VPS, e.g. $6/moPro from $25/mo
Who maintains itOne volunteer-run open source project, no companySupabase, a company with paid plans

Sources: PocketBase docs, PocketBase FAQ, PocketBase GitHub, Supabase GitHub, Supabase pricing.

Architecture: one binary vs a Postgres platform#

PocketBase is "an open source backend consisting of embedded database (SQLite) with realtime subscriptions, builtin auth management, convenient dashboard UI and simple REST-ish API", shipped as one file (PocketBase docs). Deploying it "could be" done "by just uploading the executable on your server", then adding a systemd service and optionally a reverse proxy such as NGINX or Caddy (Going to production). Everything lives in a pb_data directory next to it.

On the database, its FAQ is blunt: "PocketBase uses embedded SQLite (in WAL mode) and there are no plans for supporting other databases" (FAQ).

Supabase describes itself as "a combination of open source tools": Postgres, a Realtime server written in Elixir, PostgREST to expose the database as a REST API, GoTrue for JWT auth and a Storage API for files in S3 (Supabase GitHub). On the hosted platform you never see those pieces; you get a project with a Postgres connection string and SDKs.

Our read: the real difference is what you are responsible for. With PocketBase you own the server, the OS updates, the disk and the upgrades, but there is only one process to own. With Supabase you own your schema and policies, and the platform owns everything underneath.

The pre-1.0 warning, verbatim#

This matters more than any feature, so here it is exactly as PocketBase's docs put it today: "Please keep in mind that PocketBase is still under active development and full backward compatibility is not guaranteed before reaching v1.0.0. PocketBase is 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" (PocketBase docs). The GitHub README carries the same backward compatibility warning (GitHub).

The FAQ adds context on who stands behind it: "PocketBase is neither a startup, nor a business. There is no paid team or company behind it", and "There are no promises for maintenance and support beyond what is already available" (FAQ). It also says PocketBase "could be a great choice for small and midsize applications".

Our read: none of this is a reason to avoid it, but it changes how you run it. Pin the exact version, never auto-update, read the changelog before each upgrade, and take a backup first. If a client contract or uptime promise depends on the backend, that bus factor of one is worth weighing honestly.

Auth#

PocketBase supports identity/password (email by default, or any unique field), one-time passwords by email, OAuth2 with providers such as Google, GitHub and Microsoft, and multi-factor authentication combining any two of those (PocketBase auth). Its APIs are "fully stateless and there are no sessions in the traditional sense": tokens are not stored server-side, so logging out means the client discards the token. Superusers can impersonate users and issue API keys for server-to-server calls.

Supabase Auth covers password, magic link, OTP, social sign-in, SSO, phone sign-in (via MessageBird, Twilio or Vonage) and MFA with TOTP or phone (Supabase Auth). "Auth uses your project's Postgres database under the hood", and the user's token scopes database access row by row through RLS. The Free plan includes 50,000 MAUs and Pro 100,000, then $0.00325 per MAU (pricing).

Our read: both cover what a typical indie SaaS needs. Supabase pulls ahead if you need enterprise SSO or SMS login without wiring it yourself.

API rules vs Row Level Security#

This is the biggest day-to-day difference in how you write the app.

PocketBase gives each collection five rules: listRule, viewRule, createRule, updateRule and deleteRule (API rules docs). A rule is either locked (null, the default, superusers only), an empty string (anyone, including guests), or a filter expression. The docs' example @request.auth.id != "" means "Allow only registered users". Rules also act as filters, so a list rule can quietly return only the rows a user may see. You edit them in the admin dashboard.

Supabase uses Postgres Row Level Security. Its docs say: "Enable RLS on every table in an exposed schema", and warn that a table without RLS is "readable and writable by any role with a grant on it" (Supabase RLS). Once enabled, "no data is accessible through the API when using a publishable key, until you create policies." A typical policy reads using ( (select auth.uid()) = user_id );.

Our read: PocketBase's default (locked) is safer for beginners, and rules are quicker to write. RLS is more powerful because it is real SQL and applies however the data is reached, but forgetting to enable it on a new table is the classic Supabase mistake. Whichever you pick, test access as a logged-out user and as a second account before launch.

Realtime#

PocketBase's realtime API "is implemented via Server-Sent Events (SSE)". Clients subscribe to a whole collection (posts/*) or one record, and access is checked against the collection's ListRule or ViewRule respectively. Idle connections get a disconnect signal after 5 minutes and the SDK reconnects (PocketBase realtime).

Supabase Realtime offers three features: Broadcast ("Send low-latency messages between clients"), Presence ("Track and synchronize user state across clients") and Postgres Changes ("Listen to database changes in real-time") (Supabase Realtime). Free includes 200 concurrent connections and 2 million messages a month; Pro includes 500 connections and 5 million messages, then $10 per 1,000 connections and $2.50 per million messages (pricing).

Our read: for live-updating lists and dashboards, PocketBase's record subscriptions are enough. If you need presence (who is online) or client-to-client messaging for multiplayer or chat, Supabase has it built in.

File storage#

PocketBase "stores uploaded files in the pb_data/storage directory on the local file system" by default, and you can "switch to an external S3 compatible storage" in the dashboard. It generates thumbnails for jpg, png, gif and partially webp, and supports protected files that need a short-lived token and pass the record's View rule (PocketBase files).

Supabase Storage is a REST API over S3 with permissions enforced in Postgres (GitHub). Free includes 1 GB; Pro includes 100 GB, then $0.0213/GB (pricing).

Our read: if users upload a lot of images or video, point PocketBase at S3-compatible storage early so your VPS disk does not become the limit.

Extending: Go and JS hooks vs Edge Functions#

PocketBase "could be used as a Go or JS framework" for custom business logic, but it "doesn't support running cloud functions" (FAQ). In JavaScript, you drop *.pb.js files into a pb_hooks folder. The engine is goja, an "embedded ES5 JavaScript engine" with most of ES6, and "is not a Node.js or browser environment", so many npm packages will not work; only CommonJS modules load via require() (JS overview). For full control you import PocketBase as a Go library and compile your own binary.

Supabase Edge Functions "are developed using Deno", are "TypeScript first" and "globally distributed for low-latency" (Edge Functions). Free includes 500,000 invocations a month; Pro 2 million, then $2 per million (pricing). You can also write logic in Postgres itself with functions and triggers.

Our read: if you know Go, PocketBase as a framework is a very pleasant way to build a backend that still compiles to one file. If you live in the npm ecosystem, Supabase Edge Functions will fight you less than goja.

Backups#

PocketBase "v0.16+ comes with builtin backups and restore APIs" in the dashboard. A backup is "a full snapshot as ZIP archive of your pb_data directory", stored locally by default or in S3-compatible storage, and the docs recommend a separate bucket for backups. They also note backups can slow the app and large data sets may need another strategy (Going to production). The FAQ suggests Litestream for replication and disaster recovery (FAQ).

On Supabase, the Free plan includes no backups. Pro keeps 7 days and Team 14 days (pricing).

Our read: a backup that sits on the same VPS is not a backup. On PocketBase, send backups to S3-compatible storage from day one and do a test restore once. On Supabase Free, export your data yourself if it matters.

Scaling limits#

PocketBase scales "Only on a single server, aka. vertical". Its FAQ says that "Even without optimizations, PocketBase can easily serve 10 000+ persistent realtime connections" on "a cheap $4 Hetzner CAX11 VPS (2vCPU, 4GB RAM)" (FAQ). Note that Hetzner's own page lists the CAX11 at €6.49/mo today, marked currently unavailable (Hetzner cost-optimized). The production guide suggests raising the open file limit (LimitNOFILE=4096) under heavy realtime load and setting GOMEMLIMIT on small machines (Going to production).

Supabase does not have a single-server ceiling in the same sense: you pay for bigger compute, more database (Pro includes 8 GB per project, then $0.125/GB) and more egress (250 GB included, then $0.09/GB) (pricing).

Our read: most indie apps never outgrow one decent server. What usually forces a move is not load but needs like multiple regions, read replicas or a team that wants SQL access to production.

Cost: Supabase plans vs PocketBase on a VPS#

Supabase plans checked today (Supabase pricing):

FreeProTeam
Price$0From $25/moFrom $599/mo
Database500 MB8 GB per project8 GB per project
Egress5 GB250 GB250 GB
File storage1 GB100 GB100 GB
MAUs50,000100,000100,000
BackupsNone7 days14 days
Pausing"Free projects are paused after 1 week of inactivity"Not pausedNot paused
Notes"Limit of 2 active projects"$10/mo compute credits (one Micro instance); spend cap on by default

PocketBase itself is MIT-licensed and free (GitHub). The cost is the server. DigitalOcean's Basic Droplets start at $4/mo (512 MiB RAM, 10 GiB SSD) and $6/mo (1 GiB RAM, 1 vCPU, 25 GiB SSD, 1,000 GiB transfer). Weekly backups cost 20% of the Droplet price (DigitalOcean pricing).

Our example monthly bill (illustrative, not a quote): a small SaaS on PocketBase using a $6 Droplet plus weekly Droplet backups ($1.20) comes to $7.20/mo, before any S3-compatible bucket for offsite backups or files. The same app on Supabase is $0 if it is fine to pause when idle and has no backups, or $25/mo on Pro.

Our read: the gap is about $18 a month at the start. That is real money pre-revenue, but price your time too. If running a server costs you an evening a month, Supabase Pro can be the cheaper option for you.

Self-hosting Supabase instead#

You can run Supabase yourself. Its docs say "The fastest and recommended way to self-host Supabase is to use Docker", with Docker Compose (Supabase self-hosting). But "Self-hosted Supabase is community-supported", runs as a single project, and lacks branching, managed backups and point-in-time recovery, analytics and the Management API, among others. You take on Postgres maintenance, security hardening, backups and monitoring.

Our read: if your reason for leaving the hosted platform is cost, self-hosted Supabase is a lot of moving parts on a small VPS. PocketBase is the lighter way to self-host; hosted Supabase is the lighter way to not self-host.

Migration path: PocketBase to Postgres#

If you outgrow PocketBase, your data sits in SQLite files inside pb_data. pgloader can load a SQLite file into Postgres with a command like pgloader sqlite:///path/to/file.db pgsql://pguser@pghost/dbname (pgloader SQLite docs). That moves tables, not your app. You would also need to:

  1. Rewrite each collection's API rules as RLS policies.
  2. Move uploaded files into the new storage and update paths.
  3. Port pb_hooks or Go hooks to Edge Functions or your own server.
  4. Handle user accounts and passwords separately; test this on a copy first, since auth systems store credentials differently.
  5. Swap the PocketBase SDK calls in your frontend for the new client.

Our read: keep business logic in your own modules rather than scattered through hooks, and the move stays manageable.

Decision table by app type#

Your appOur pickWhy
Side project or weekend MVPPocketBaseOne file, cheap VPS, no pausing
Internal tool for one businessPocketBaseSmall user count, single server is plenty
Desktop or local-first companion backendPocketBaseShips as one binary you can bundle
Prototype you want online for $0Supabase FreeNo server, accept the 1 week pause rule
B2B SaaS with paying customersSupabase ProManaged backups, Postgres, no ops
App needing SSO or SMS loginSupabaseBuilt in
Chat, multiplayer or presence featuresSupabaseBroadcast and Presence
Analytics-heavy app with SQL reportingSupabasePostgres and its extensions
You know Go and want one deployablePocketBase as a Go frameworkCustom logic, still one binary
Client work with uptime obligationsSupabasePocketBase's own pre-1.0 warning

Our pick by situation#

  • Solo developer, pre-revenue, comfortable with Linux: PocketBase on a small VPS, version pinned, backups to S3. You get a full backend for the price of a coffee.
  • Solo developer who hates ops: Supabase. Start on Free, move to Pro the week you get your first paying customer so the project never pauses and you have backups.
  • Anything you sell on an SLA: Supabase Pro.
  • Not sure: build the first version on whichever you can ship faster this week. Our read is that most indie projects die from lack of users, not from the wrong backend.

When it works, see our product launch checklist for bootstrapped makers before you go live.

Frequently asked questions#

Is PocketBase production ready?#

Its own docs say PocketBase is still under active development, that full backward compatibility is not guaranteed before v1.0.0, and that it is "NOT recommended for production critical applications yet" unless you are fine reading the changelog and applying manual migration steps. Its FAQ also calls it a great choice for small and midsize applications. Our read: fine for small apps if you pin versions and read release notes before upgrading.

Is PocketBase cheaper than Supabase?#

Usually, once you are past Supabase's free tier. PocketBase is free MIT software, so the cost is the server: a DigitalOcean Basic Droplet with 1 GiB RAM is $6/mo. Supabase Free is $0 but pauses inactive projects after a week; Pro starts at $25/mo with $10 of compute credits included. Remember to count your own time running the server.

Can PocketBase scale?#

Only vertically. The PocketBase FAQ says it scales on a single server and that it can serve 10,000+ persistent realtime connections on a $4 Hetzner CAX11 (2 vCPU, 4 GB RAM). It uses embedded SQLite in WAL mode and has no plans to support other databases. If you need multiple app servers or regions, Supabase or another Postgres host is the better fit.

Can I move from PocketBase to Postgres or Supabase later?#

Yes, but it is a migration, not a switch. PocketBase data lives in SQLite files in pb_data, and tools such as pgloader can load a SQLite file into Postgres. You would still need to rewrite API rules as RLS policies, move files, port hooks and handle user auth separately. Plan for a weekend at least, not an afternoon.

Can I self-host Supabase instead of PocketBase?#

Yes. Supabase's docs recommend Docker Compose for self-hosting, but it is community-supported, runs as a single project, and lacks managed backups, point-in-time recovery, branching and some other platform features. You also take on Postgres maintenance and security yourself. If you want one small self-hosted backend, PocketBase is far less to run.

Ship it, then launch it#

ZeroRaised is a launch directory for products built without institutional VC. Once your backend is live, submit your product for free. For more comparisons and guides on building without investors, join the ZeroRaised newsletter.

Sources#

Frequently asked questions

Is PocketBase production ready?

Its own docs say PocketBase is still under active development, that full backward compatibility is not guaranteed before v1.0.0, and that it is 'NOT recommended for production critical applications yet' unless you are fine reading the changelog and applying manual migration steps. Its FAQ also calls it a great choice for small and midsize applications. Our read: fine for small apps if you pin versions and read release notes before upgrading.

Is PocketBase cheaper than Supabase?

Usually, once you are past Supabase's free tier. PocketBase is free MIT software, so the cost is the server: a DigitalOcean Basic Droplet with 1 GiB RAM is $6/mo. Supabase Free is $0 but pauses inactive projects after a week; Pro starts at $25/mo with $10 of compute credits included. Remember to count your own time running the server.

Can PocketBase scale?

Only vertically. The PocketBase FAQ says it scales on a single server and that it can serve 10,000+ persistent realtime connections on a $4 Hetzner CAX11 (2 vCPU, 4 GB RAM). It uses embedded SQLite in WAL mode and has no plans to support other databases. If you need multiple app servers or regions, Supabase or another Postgres host is the better fit.

Can I move from PocketBase to Postgres or Supabase later?

Yes, but it is a migration, not a switch. PocketBase data lives in SQLite files in pb_data, and tools such as pgloader can load a SQLite file into Postgres. You would still need to rewrite API rules as RLS policies, move files, port hooks and handle user auth separately. Plan for a weekend at least, not an afternoon.

Can I self-host Supabase instead of PocketBase?

Yes. Supabase's docs recommend Docker Compose for self-hosting, but it is community-supported, runs as a single project, and lacks managed backups, point-in-time recovery, branching and some other platform features. You also take on Postgres maintenance and security yourself. If you want one small self-hosted backend, PocketBase is far less to run.