Supabase Cloud vs self-hosted: which model fits?

Assessing a cloud exit or looking for an operator? WZ-IT plans a Supabase migration from €3,490 and can run the target on managed or customer-controlled infrastructure.

Supabase Cloud and self-hosted Supabase use the same open-source core, but they are not identical products. Supabase operates the cloud platform. In a self-hosted setup, the runtime components run on another infrastructure and operational responsibility moves to its operator.

The decision is therefore not simply “cloud versus one server”. Features, availability, data paths, recovery, staffing and incident ownership all matter.

Comparison at a glance

The official Supabase documentation explicitly lists cloud capabilities unavailable in self-hosting: branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL and the platform management API.

What both models provide

The self-hosted stack includes the core runtime:

• PostgreSQL
• Auth
• Storage
• Realtime
• REST and GraphQL APIs
• Functions runtime
• Studio
• API gateway and connection pooling

Available does not mean operated in the same way. Self-hosted functions run on the target instance rather than an automatically distributed global network. Storage needs a defined backend and separate protection. Studio needs hardening, and administrative endpoints should not be exposed indiscriminately.

When Supabase Cloud is usually the better fit

Cloud is often appropriate when:

• an application is still at an early stage,
• the team prioritises development speed,
• there is little internal platform capacity,
• managed backups and platform metrics are wanted,
• load and user growth remain uncertain,
• no customer-controlled infrastructure is required.

A self-managed server can look cheaper on an infrastructure invoice. The calculation changes once availability, updates, backup assurance and recovery are included.

When self-hosting can be appropriate

Self-hosting is plausible when:

• a specific cloud, data-centre or on-premises location is required,
• private networks and internal systems need direct integration,
• the platform should use an existing backup and monitoring estate,
• capacity and cost need more explicit sizing,
• an isolated deployment is required,
• the company or a provider can own platform operations.

The desire for control is not sufficient by itself. The organisation must exercise that control: who reviews updates, responds to alerts, restores storage and decides how long PostgreSQL may be unavailable?

Managed self-hosting as a third option

Managed self-hosting sits between Supabase Cloud and fully internal operations. The platform runs on a dedicated or customer-controlled environment while an operator takes responsibility for an agreed scope:

• installation and hardening
• monitoring and alerting
• updates and tested deployments
• database and storage backups
• restore tests
• incident response according to service level
• technical documentation

This keeps control over location and infrastructure without pushing every platform task into the application team.

Leaving Cloud is a migration, not a toggle

A cloud-to-self-hosted move covers at least:

1. PostgreSQL roles, schema and data
2. auth users, providers, SMTP, JWT and redirects
3. storage metadata and actual objects
4. functions, secrets and webhooks
5. realtime, pooling and domains
6. frontend and server configuration
7. test, cutover and rollback

The official restore guide intentionally focuses on database restoration and states that storage objects and functions require separate handling.

Decision matrix

The decision should be reviewed as the application changes. Users, storage, egress, operational requirements and internal capacity all evolve.

Sources

• Supabase: self-hosting and feature differences
• Supabase: restore a Cloud project
• Supabase: pricing
• Supabase: self-hosted functions