Migrate from Supabase
Supabase is excellent managed Postgres, auth, storage, and realtime — but a Cloudflare-native move is no drop-in. Postgres → D1 and Storage → R2 are mostly config; auth, RLS, and realtime are real rebuilds. Here's exactly which, then the agent skill that does the work.
pnpm create microservices-app@latest --template saas-starter-sveltekit Local-first · no login · Node ≥ 20 · driven by the supabase-to-microservices agent skill
Concept mapping
| Supabase | microservices.sh / Cloudflare | Note |
|---|---|---|
| Postgres tables | D1 (SQLite) via Drizzle | Type conversions: uuid→text, timestamptz→epoch, jsonb→text |
| Row Level Security (RLS) | Permission checks at the Worker boundary | No DB-enforced RLS in D1 — enforced in code |
| Supabase Auth (password, OAuth, magic link) | Passwordless email-code auth | Passwords & social do not carry over |
| Storage buckets | R2 buckets | Public/signed-URL model differs |
| Realtime (postgres changes, presence) | Durable Objects + WebSocket | No drop-in — rebuilt |
| Edge Functions (Deno) | Workers / module use-case files | |
| pg_cron / pgvector | Cron Triggers / Vectorize |
The migration
Inventory tables, types, RLS policies, auth providers, storage buckets, realtime subscriptions, and row counts before moving anything.
Start from a customer-backed template; add email for transactional mail and payment if users are billed.
Convert Postgres types to SQLite (uuid→text, timestamptz→epoch, jsonb→text, serial→autoincrement) and recreate FKs and indexes.
Export as CSV/SQL, transform to D1 column types, load to local D1 first, verify counts and joins before you approve the remote import.
Import email + id into the customer table; users re-verify by email code on first visit; map every RLS policy to an explicit Worker-boundary check.
What doesn't port 1:1
pnpm create microservices-app@latest --template saas-starter-sveltekit Lands on these modules
Still deciding? Read the evaluation-intent comparison: microservices.sh vs Supabase & BaaS →