# Migrating PocketBase to Code: The Complete Playbook (2026)

- Tool: No-Code to Code Migrations
- Last updated: July 2026

## TL;DR

PocketBase is one of the best-ownership backends available — MIT-licensed, single binary, and uniquely, you hold the password hashes in your own SQLite file. Migrate only when you've hit genuine scale (SQLite horizontal-scaling limits, >10K concurrent connections) or compliance walls (no SOC 2, no DPA). Typical migration: 4–8 weeks. Don't migrate just to 'professionalize.'

## Platform status

- Status: active — MIT-licensed, single-maintainer project (Bulgaria/EU, pre-1.0). Frequent releases (v0.23+) as of July 2026. No formal corporate entity and no DPA — the operator carries the full compliance burden. PRs currently restricted to collaborators due to LLM-spam mitigation.
- Migration urgency: low
- Typical timeline: 4–8 weeks
- Typical cost: $13K–$25K (agency, fixed)

## Why migrate

PocketBase's limitations are architectural, not platform-risk. The SQLite single-node ceiling and single-maintainer structure are the honest reasons teams migrate — not because the platform is dying.

- **SQLite single-node scaling ceiling** — PocketBase cannot scale horizontally. Once your app requires multiple servers or exceeds ~10,000 concurrent connections, SQLite's locking model becomes a hard blocker — no workaround exists within PocketBase.
- **Single-maintainer risk for production workloads** — No corporate entity, no DPA, no formal SLA. Enterprise procurement and regulated industries (healthcare, finance) cannot accept a single-maintainer dependency regardless of how good the software is.
- **Pre-1.0 backward-compatibility gaps** — Backward compatibility is not guaranteed between minor versions; migrations can break unexpectedly on upgrades. Production systems that can't tolerate migration risk need a versioning contract PocketBase doesn't offer.
- **Complex server-side logic outgrows pb_hooks** — PocketBase hooks can be written in Go (extending the binary) or JavaScript (jsvm sandbox). Complex server-side logic eventually requires writing Go — which is a real language requirement, not a no-code path.
- **HIPAA / SOC 2 compliance requirements** — PocketBase has no compliance certifications. Any regulated workload (healthcare, finance, enterprise) must move to a certified managed backend.

## What you can export

PocketBase is the most portable backend in this category. Your SQLite file IS the database, AND it contains password hashes — making PocketBase uniquely the only backend here where a no-password-reset migration is genuinely feasible.

| Asset | Exportable | How |
| --- | --- | --- |
| Data | yes | pb_data/data.db is the entire data store — copy the file. Litestream can replicate it to S3 with point-in-time recovery. |
| Code | partial | PocketBase is a Go framework — your custom Go hooks and extensions are your code and fully portable. The visual admin UI config is stored in the SQLite file. |
| Design/UI | no | PocketBase's admin UI is the platform's own interface. Your frontend application is separate code you own and is not affected. |
| Logic/Workflows | yes | pb_hooks/ contains Go source files or .js files (jsvm) that are your code and export with the project directory. |
| Users & Auth | yes | Password hashes live in your own pb_data/data.db SQLite file — you literally hold them. A custom bcrypt import script can migrate hashes to the target auth provider. |
| File Storage | yes | pb_data/storage/ contains all uploaded files in a directory structure mirroring your collection records. |

## Stack mapping

The target stack is Next.js (App Router) + Supabase (PostgreSQL) — a managed, horizontally scalable replacement for PocketBase's single-binary model.

| Platform concept | Code equivalent |
| --- | --- |
| PocketBase collections | Supabase / PostgreSQL tables |
| pb_hooks/ (Go hooks / jsvm JS hooks) | Supabase Edge Functions (Deno/TypeScript) or Next.js API Routes |
| PocketBase Auth (email / OAuth2) | Supabase Auth |
| PocketBase realtime (SSE subscriptions) | Supabase Realtime (WebSockets) |
| pb_data/storage/ (file storage) | Supabase Storage or S3/R2 |
| Single Go binary deploy | Vercel + Supabase (serverless) OR self-hosted Next.js + PostgreSQL container |

## Migration roadmap

A 4–8 week migration where the file copy in Phase 1 secures your full dataset and the password-hash migration in Phase 5 is the standout opportunity. Plan both explicitly before writing a single line of code.

### Phase 1: Audit & Secure (3–5 days)

- Copy pb_data/data.db — this single file is your entire database, auth records, and file metadata
- Copy pb_data/storage/ — all uploaded files; measure total size for your target storage provider
- Document every collection schema and its relations (especially JSON fields and relation types)
- Inventory pb_hooks/: catalog every hook trigger (before/after create/update/delete) and its logic
- Check PocketBase version; if behind on a pre-1.0 release, test an upgrade on a copy first

> Watch out: The SQLite file is your only authoritative backup. Copy it before touching anything else.

### Phase 2: Schema Migration (3–5 days)

- Convert SQLite schema to PostgreSQL DDL (TEXT → VARCHAR, INTEGER → INT, BLOB → BYTEA)
- Write a schema-validation script and run it on a sample before bulk import
- Define Supabase RLS policies that mirror PocketBase's collection-level access rules
- Create all tables, indexes, and foreign key constraints in Supabase

### Phase 3: Data Migration (3–7 days)

- Script SQLite → PostgreSQL row migration (sqlite3 dump → psql import or ETL script)
- Validate row counts and spot-check data integrity across all collections
- Migrate pb_data/storage/ files to Supabase Storage or S3/R2

### Phase 4: Logic Port (1–3 weeks)

- Rewrite pb_hooks/ logic as Supabase Edge Functions or Next.js API Routes
- Replace PocketBase SDK calls with Supabase SDK equivalents
- Verify OAuth2 providers (Google, GitHub, etc.) are re-authorized with the new callback URLs

> Watch out: jsvm hooks use PocketBase's sandboxed API, not standard Node.js — they define the behavior but don't port directly to Deno/Edge Functions.

### Phase 5: Auth Migration & Cutover (1 week)

- Write and test custom bcrypt hash import script for Supabase auth.users
- Test login parity on a staging environment with real user records
- Run both backends in parallel for 48–72 hours; verify parity
- Switch DNS, update frontend API URLs, deprecate PocketBase instance

> Watch out: The password-hash migration requires careful testing — validate that imported hashes authenticate correctly in Supabase before cutting over production traffic.

## Cost paths

| Path | Cost | Timeline | Fits |
| --- | --- | --- | --- |
| DIY (self-directed with AI tools) | $0–500 + time | 2–4 months part-time | Developers comfortable with SQLite, PostgreSQL schema design, and Go or JavaScript who want maximum control over the password-hash migration script. |
| Freelancer | $3K–8K | 4–8 weeks | Teams with moderate hook complexity and a developer available to own handoff and ongoing maintenance of the new stack. |
| Agency (RapidDev) | $13K–25K fixed | 4–8 weeks | Teams that want a guaranteed timeline, a tested password-hash migration, full data integrity validation, and a single team owning schema, logic, auth, and cutover. |

## Risks and mitigations

- **SQLite → PostgreSQL type mismatches** — Write a schema-validation script before bulk data import. Pay particular attention to REAL/NUMERIC types, JSON storage patterns, and PocketBase's relation fields.
- **pb_hooks jsvm code is not portable to Deno/Edge Functions** — jsvm hooks use PocketBase's sandboxed API, not standard Node.js. Treat them as business-logic specs and rewrite against the new runtime — they are not copy-paste portable.
- **Single-maintainer abandonment before migration completes** — If you're on a critical migration path, fork the MIT-licensed source before starting. The fork ensures you have a stable, known-good version to run until cutover is complete.
- **Realtime SSE → WebSocket subscriber count differences** — PocketBase Realtime uses SSE; Supabase Realtime scales differently with WebSockets. Load-test Supabase Realtime with your expected concurrent connections before cutover — don't assume parity.

## Stay or go

Stay if:

- Your app runs on a single server, SQLite fits the data volume, and you value zero-cost self-hosting with maximum ownership — PocketBase is genuinely excellent for this profile.
- Your team writes Go and wants a framework, not a managed service — extending PocketBase as a Go library is a real, documented production pattern.
- Your compliance requirements are zero (personal projects, internal tools, prototypes) — no other backend gives you this much ownership at this low a cost.
- You're pre-1.0 on a feature build and horizontal scaling isn't on the roadmap — don't pay managed-Postgres costs you don't need yet.

Go if:

- You need horizontal scaling, multi-region deployment, or more than ~10,000 concurrent connections — SQLite's architecture is a hard ceiling.
- You need SOC 2, ISO 27001, or HIPAA certification for enterprise sales or regulated data — PocketBase has none of these.
- The single-maintainer risk is unacceptable for your business continuity requirements or procurement processes.

PocketBase is one of the best-ownership backends available. Don't migrate to 'professionalize' a working system — migrate only when you've hit a genuine scale or compliance wall. The password-hash portability is a rare advantage you won't find on other platforms.

## Migration checklist

- Copy pb_data/data.db immediately — This single file is your entire database, all auth records, and all file metadata — it is the most important backup you will ever make for this project.
- Copy pb_data/storage/ and measure total size — All uploaded files live here; sizing the directory determines which storage provider tier you need.
- Document every collection schema and its relations — Especially JSON fields and select/relation types — these require the most care during SQLite → PostgreSQL schema conversion.
- Inventory pb_hooks/ — catalog every hook trigger and its logic — These hooks define your server-side business logic; each one becomes an Edge Function or API Route in the new stack.
- Verify PocketBase version and test upgrades on a copy — Pre-1.0 backward compatibility is not guaranteed — if you're behind on releases, validate an upgrade in isolation before migrating.
- List all OAuth2 providers configured — Google, GitHub, and other OAuth tokens must be re-authorized with new callback URLs after migration; gather provider credentials now.
- Plan and test the password-hash migration script — PocketBase's bcrypt hashes must be imported to the new auth provider with a custom script — test hash compatibility on a staging environment before touching production.

## Frequently asked questions

### Can I export my PocketBase data?

Yes — completely. pb_data/data.db is your entire database in a single SQLite file. Copy it and you have a full backup of all collections, records, auth users, and file metadata. This is the most portable data story in the BaaS space.

### Can I migrate my users' passwords without a forced reset?

Yes — and this is PocketBase's unique advantage. Your bcrypt password hashes live in your own pb_data/data.db file. A custom import script can port them to Supabase auth.users. Test hash compatibility on staging before touching production. PocketBase is the only backend in this category where password migration without a forced reset is genuinely feasible.

### How long does a PocketBase migration take?

Typically 4–8 weeks. The schema migration (SQLite → PostgreSQL) is mostly mechanical. The hook rewrite and the password-hash import script are where specialist time is needed. Simple projects with few hooks can complete in 3–4 weeks; complex hook-heavy backends may need 6–8.

### Is PocketBase shutting down?

No. As of July 2026, PocketBase is actively maintained with frequent releases (v0.23+). The platform risk is not shutdown — it's single-maintainer dependency and the SQLite scaling ceiling. Migrate when those constraints bite your workload, not because of platform survival concerns.

### What happens to pb_hooks/ code when I migrate?

pb_hooks/ contains your server-side logic as Go source files or JavaScript (jsvm). The Go files are standard Go and portable. The JavaScript files use PocketBase's sandboxed jsvm API — not standard Node.js — so they don't port directly to Deno or Edge Functions. Treat jsvm hooks as business-logic specifications and rewrite them against the new runtime.

### What's the target stack after migrating from PocketBase?

Next.js (App Router) + Supabase (PostgreSQL) is the standard target. PocketBase collections map to Supabase tables (with SQLite→PostgreSQL type conversion); pb_hooks become Edge Functions or API Routes; PocketBase Auth migrates to Supabase Auth with bcrypt hash import; file storage moves to Supabase Storage or S3/R2.

### Should I just self-host PocketBase instead of migrating to managed Postgres?

Yes — if you're on a single server and SQLite fits your data volume, self-hosting PocketBase is a legitimate and excellent option. The MIT license, zero-cost model, and maximum data ownership make it genuinely hard to beat for single-server workloads. Only migrate when you've hit the horizontal-scaling ceiling or need compliance certifications.

### How much does a PocketBase migration cost if I hire an agency?

RapidDev offers fixed-price PocketBase migrations at $13K–$25K over 4–8 weeks, including schema conversion, hook rewriting, password-hash migration, file storage transfer, and cutover. Free scoping call at rapidevelopers.com to size your project before committing.

---

Source: https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-pocketbase-project-to-code
© RapidDev — https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-pocketbase-project-to-code