Ensure feature parity between Supabase Cloud and Self-Hosted / Local Development

[Saint-Franklin1]

Currently, Supabase Cloud offers several key features not available in self-hosted or local development environments. This creates friction for teams that want consistent behavior across environments (dev, staging, prod). Lack of parity causes bugs, wasted time, and makes local development unreliable as a mirror of production.

Problems observed:

Missing features in self-hosted/local that exist in Cloud:

Logs (auth, storage, DB queries, API requests)
Backups and restore
Email template customization
Reports and insights
Certain dashboard UI tools
Inconsistent behavior between Cloud vs local:

Real-time subscriptions sometimes fail locally
RLS policies behave differently or lack the same debugging tools
Storage metadata handling differs
No clear documentation enumerating what is and is not available in self-hosted. Developers only discover limitations after failed attempts.

Impact:

Slows down adoption for teams requiring self-hosted (compliance, cost, private infra).
Undermines CI/CD pipelines where dev/staging are self-hosted but prod is in Supabase Cloud.
Reduces trust in Supabase as a production-ready stack when local cannot reliably mirror prod.

Proposed improvements:

1. Publish a clear matrix of features available in Cloud vs self-hosted vs local dev.
2. Where possible, implement the missing features in self-hosted (e.g. logs, backups, email customization).
3. Ensure consistency in SDK behavior between environments.
4. Provide fallback or stubs for Cloud-only features to prevent “silent failures” locally.

Value:
Achieving parity or at least documented transparency will improve developer trust, speed adoption in enterprise, and reduce friction in day-to-day development.