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
| Criterion | Supabase Cloud | Self-hosted Supabase |
|---|---|---|
| Infrastructure | Operated by Supabase | Customer, cloud or managed infrastructure |
| Updates | Platform-managed | Planned and tested by the operator |
| Backups | Managed according to plan | Custom backup and restore architecture |
| PITR | Plan-dependent add-on | Built using PostgreSQL WAL archiving |
| Branching | Platform capability | Not included automatically |
| Monitoring | Platform metrics and logs | Custom metrics, logs, alerts and response |
| Projects | Organisations and multiple projects | Self-hosted Studio manages one stack as one project |
| Scaling | Platform and compute options | Resources and component separation designed by operator |
| Operating location | Available Supabase regions | Chosen within the target architecture |
| Responsibility | Supabase plus customer application duties | Operator plus customer platform and application duties |
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:
- PostgreSQL roles, schema and data
- auth users, providers, SMTP, JWT and redirects
- storage metadata and actual objects
- functions, secrets and webhooks
- realtime, pooling and domains
- frontend and server configuration
- 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
| Starting point | Sensible default |
|---|---|
| MVP without infrastructure constraints | Supabase Cloud |
| Production app without a platform team | Cloud or managed self-hosting |
| Fixed operating location and internal IT ownership | Self-hosted |
| Fixed operating location without an operations team | Managed self-hosting |
| Cloud project with unclear dependencies | Assessment before migration |
| Critical app with very low downtime | Custom migration and HA architecture |
The decision should be reviewed as the application changes. Users, storage, egress, operational requirements and internal capacity all evolve.
