Context
I currently have one service using schema service_a.
Migration history is stored in the supabase_migrations schema in the schema_migrations table.
I now want to add another service with:
• its own DB schema: service_b
• its own distinct migration stream/history
Problem If both services share the same schema_migrations table, migration version values can conflict (since version is the PK), unless all services coordinate a single global version sequence.
Request Is there a supported way to configure either:
For example: • service_a_supabase_migrations.schema_migrations • service_b_supabase_migrations.schema_migrations
or
• supabase_migrations.service_a_schema_migrations • supabase_migrations.service_b_schema_migrations
Alex Jones is seeking advice on how to configure separate migration histories for two backend services using the same Supabase instance. Each service has its own database schema, and Alex wants to avoid conflicts in migration version values by using custom schemas or tables for migration history.
What is service a in this example? Are we still working within the same app context or are you using different schemas for different frontend projects?
Service A and service B are separate backend node services. The run separately. They have their own database schema, with distinct set of tables. They share a supabase instance.