Migration snapshot
ActivePlatform
a PocketBase
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.
Typical timeline
4–8 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a PocketBase
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 can you actually take with you?
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 | Can you export it? | How | Notes |
|---|---|---|---|
| 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. | Trivially portable. A file copy is your full database backup. |
| 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. | pb_hooks/ JavaScript files and custom Go extensions are standard code you own and can reuse. |
| 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. | No action needed — your frontend lives outside PocketBase. |
| Logic/Workflows | Yes | pb_hooks/ contains Go source files or .js files (jsvm) that are your code and export with the project directory. | jsvm hooks use PocketBase's sandboxed API, not standard Node.js — they are specs for rewriting, not directly portable to other runtimes. |
| 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. | This is PocketBase's unique advantage: it is the only backend in this category where password migration is genuinely feasible without forced reset. |
| File Storage | Yes | pb_data/storage/ contains all uploaded files in a directory structure mirroring your collection records. | Copy the directory and re-upload to your target storage (Supabase Storage, S3, or R2). |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is Next.js (App Router) + Supabase (PostgreSQL) — a managed, horizontally scalable replacement for PocketBase's single-binary model.
a PocketBase
PocketBase collections
In code
Supabase / PostgreSQL tables
SQLite types map mostly mechanically to PostgreSQL (TEXT → VARCHAR, INTEGER → INT, BLOB → BYTEA) — write a schema-validation script before bulk import.
a PocketBase
pb_hooks/ (Go hooks / jsvm JS hooks)
In code
Supabase Edge Functions (Deno/TypeScript) or Next.js API Routes
jsvm hooks use PocketBase's sandboxed API — treat them as business-logic specs, not portable code; rewrite against the new runtime.
a PocketBase
PocketBase Auth (email / OAuth2)
In code
Supabase Auth
Password hashes in pb_data/data.db — a custom bcrypt import script can port them to Supabase auth.users; test login parity before cutover.
a PocketBase
PocketBase realtime (SSE subscriptions)
In code
Supabase Realtime (WebSockets)
PocketBase uses SSE; Supabase Realtime uses WebSockets — load-test Supabase Realtime with expected concurrent connections before cutover.
a PocketBase
pb_data/storage/ (file storage)
In code
Supabase Storage or S3/R2
Copy the storage directory and re-upload files; update any file URL references in your frontend.
a PocketBase
Single Go binary deploy
In code
Vercel + Supabase (serverless) OR self-hosted Next.js + PostgreSQL container
Serverless via Vercel reduces operational overhead; Docker Compose (Next.js + Postgres) is valid for teams that want a similar single-host model.
The 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.
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.
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
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
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.
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.
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (self-directed with AI tools)
$0–500 + time
2–4 months part-time
Fits
Developers comfortable with SQLite, PostgreSQL schema design, and Go or JavaScript who want maximum control over the password-hash migration script.
Risks
The bcrypt hash import script for Supabase auth.users is not a standard procedure — it requires custom work and careful testing. SQLite→PostgreSQL type mapping can surface surprises on JSON fields and relation types.
Freelancer
$3K–8K
4–8 weeks
Fits
Teams with moderate hook complexity and a developer available to own handoff and ongoing maintenance of the new stack.
Risks
The password-hash migration is specialist work — verify the freelancer has done it before, not in theory.
Agency (RapidDev)
Done-for-you$13K–25K fixed
4–8 weeks
Fits
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
Minimal — fixed price with scope agreed upfront. Free scoping call available at rapidevelopers.com.
The real risks — and how to defuse them
SQLite → PostgreSQL type mismatches
Mitigation: 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
Mitigation: 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
Mitigation: 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
Mitigation: 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.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
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.
Migrate 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.
Our honest verdict
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.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
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.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.