Choosing the Right Supabase Environment Strategy (Branching vs Multiple Projects vs something else?)
🤷other
Hi everyone,
we currently run our whole app on a single Supabase Cloud project (Free plan, upgrading to Pro soon) and are preparing for a closed beta launch next month.
That project already contains ~15 schemas, multiple Storage buckets, many RLS policies, Postgres functions, and Realtime.
During development we already broke things multiple times, mostly due to RLS mistakes (e.g. recursion), and we know this will happen again. At the same time, the database is full of sandbox data (fake users, Stripe test data, test integrations), which we still need for development and testing.
We now need a proper environment strategy: a safe dev/sandbox setup, a stable production setup, and a way to promote schema and logic changes between them without risking production.
We saw two options in Supabase:
* Project branching
* Multiple projects with CI/CD (as in “Managing Environments”)
For a SaaS with heavy RLS, multiple schemas, Storage, Functions, and Realtime:
* Is branching meant for this kind of workflow?
* Or is running multiple Supabase projects the recommended approach?
* How is sandbox data (e.g. Stripe test mode) usually handled?
* How are you dealing with stuff like that? Do Supabase branches handle this type of situation or do we need to customize two projects and somehow implement a custom workflow through our pipelines?
If this is the wrong channel, please let me know and I will move it.
Thanks for any guidance!
we currently run our whole app on a single Supabase Cloud project (Free plan, upgrading to Pro soon) and are preparing for a closed beta launch next month.
That project already contains ~15 schemas, multiple Storage buckets, many RLS policies, Postgres functions, and Realtime.
During development we already broke things multiple times, mostly due to RLS mistakes (e.g. recursion), and we know this will happen again. At the same time, the database is full of sandbox data (fake users, Stripe test data, test integrations), which we still need for development and testing.
We now need a proper environment strategy: a safe dev/sandbox setup, a stable production setup, and a way to promote schema and logic changes between them without risking production.
We saw two options in Supabase:
* Project branching
* Multiple projects with CI/CD (as in “Managing Environments”)
For a SaaS with heavy RLS, multiple schemas, Storage, Functions, and Realtime:
* Is branching meant for this kind of workflow?
* Or is running multiple Supabase projects the recommended approach?
* How is sandbox data (e.g. Stripe test mode) usually handled?
* How are you dealing with stuff like that? Do Supabase branches handle this type of situation or do we need to customize two projects and somehow implement a custom workflow through our pipelines?
If this is the wrong channel, please let me know and I will move it.
Thanks for any guidance!
