Self-hosting, and why vendor lock-in looks different for Supabase

Every core piece of Supabase — the auth server (GoTrue), the realtime engine, the storage API, PostgREST itself — is genuinely open source, and Supabase publishes an official self-hosting setup using Docker Compose (Docker & Containers' own domain covers exactly this mechanism) that runs the entire stack on infrastructure you control, not Supabase's own cloud. This is a real, substantive difference from Vercel's, Railway's, and Render's own proprietary platforms, where the actual deployment mechanics have no self-hosted equivalent at all.

If Supabase's managed hosting became unacceptably expensive, or the company ceased operating entirely, a team using Supabase has a real, documented path to running the same stack elsewhere — this is a fundamentally different risk profile than depending on Vercel's own proprietary ISR mechanism or Railway's own private-networking implementation, neither of which has any equivalent outside that specific platform. Because the actual data lives in real, standard Postgres (lesson 1's own core point), even a worst-case migration away from Supabase entirely means migrating a Postgres database — a well-understood, genuinely common operation — not reverse-engineering a proprietary data format.

Self-hosting trades Supabase's managed-infrastructure convenience (automatic backups, scaling, security patching, the dashboard) for real, ongoing operational responsibility a team takes on themselves — this is the exact same fundamental trade-off Railway's and Render's own domains covered for "managed database vs. running your own," just applied to an entire backend platform instead of one database. A team self-hosting Supabase needs to handle Postgres upgrades, security patches for every component, backup verification, and scaling — all things the managed service otherwise handles invisibly.

Because RLS policies (lesson 2) and migrations (lesson 9) are expressed as ordinary SQL, they transfer to a self-hosted instance with zero changes — the actual application logic and security model are genuinely portable. Specific managed-dashboard conveniences (one-click backups with a retention UI, built-in usage analytics, Supabase's own support) don't have an automatic self-hosted equivalent and would need to be rebuilt or replaced with a team's own tooling.

A team should still evaluate Supabase-specific dependencies honestly — Edge Functions' Deno-specific code, heavy reliance on Supabase's own client libraries' exact API — rather than assuming "it's open source" means zero migration cost under any circumstance. But the database itself, the security model, and the core backend mechanics genuinely carry far less platform-specific risk than an equivalent amount of logic built around a fully proprietary BaaS would.