Clarification on Stripe sync engine schema migrations (local dev vs Supabase integration)
🤷other
Hi,
I'm trying to understand the intended workflow for managing the
My setup looks like this:
Production (I haven't done anything there yet):
- Stripe Sync Engine installed via the Supabase integrations page
Local development
- Local Supabase running in Docker
- Stripe sync engine running separately (also in Docker)
- Using the
What I'm unsure about is who is supposed to own the schema migrations in this scenario.
1. When installing the Stripe sync engine via the Supabase integrations page, does the integration automatically create and manage the
2. If the integration does not manage schema migrations, does that mean I am responsible for:
- Running the SQL migrations from
- Applying those same migrations to the production database as well?
3. If the integration does manage the schema in production, what is the recommended workflow to keep local and production schemas in sync?
4. What happens if the integration in production upgrades to a newer version of the sync engine with new migrations added to the package while my local environment is still on an older version and those migrations haven't been applied? Could this create schema drift where the production integration expects columns or tables that don't exist?
I'm also using declarative schemas and want to create functions/triggers that depend on tables in the
Thanks!
I'm trying to understand the intended workflow for managing the
stripeMy setup looks like this:
Production (I haven't done anything there yet):
- Stripe Sync Engine installed via the Supabase integrations page
Local development
- Local Supabase running in Docker
- Stripe sync engine running separately (also in Docker)
- Using the
@supabase/stripe-sync-enginestripeWhat I'm unsure about is who is supposed to own the schema migrations in this scenario.
1. When installing the Stripe sync engine via the Supabase integrations page, does the integration automatically create and manage the
stripe2. If the integration does not manage schema migrations, does that mean I am responsible for:
- Running the SQL migrations from
@supabase/stripe-sync-engine- Applying those same migrations to the production database as well?
3. If the integration does manage the schema in production, what is the recommended workflow to keep local and production schemas in sync?
4. What happens if the integration in production upgrades to a newer version of the sync engine with new migrations added to the package while my local environment is still on an older version and those migrations haven't been applied? Could this create schema drift where the production integration expects columns or tables that don't exist?
I'm also using declarative schemas and want to create functions/triggers that depend on tables in the
stripeThanks!
