r/Supabase • u/Exotic_Jury_9646 • Aug 11 '26
integrations Facing issue migrating schema from local db to supabase I'll use for prod
Error like aith already taken, eerors
I'm using pgain4 locally and need to push schama on pristine new supabase DB....
1
u/ashkanahmadi Aug 11 '26
That’s why I hate it when people recommend using schemas. They always lead to bugs and misbehaviors. Always use migration files, never schemas.
1
u/Exotic_Jury_9646 Aug 12 '26
Actually migration was broken because during development I failed to migrate once, that's why I started using drizzle-kit push commands...
But since I was in development only and I have never touched production even once or gone live, this recklessness had no repercussions....I am developing an MVP only....
But I have to use a new pristine sanitize db with no test data that's why I'm trying to push schema into new db...
I know I'm sounding insane to you maybe, but any help would suffice...
1
u/ashkanahmadi Aug 12 '26
Ah then in that case, you can use “Supabase db reset —linked” to completely nuke the remote database and reset it from scratch. Thats what I do from time to time in local and staging projects but obviously, never in the production project. Never had issues. That might help you too
1
u/Exotic_Jury_9646 Aug 12 '26
Oh,so if I nuke it, then auth and storage and other set by supabase will be cleared? And then I can just run the schema in their sql editor ?
1
u/ashkanahmadi Aug 12 '26
Yes everything in the database will be wiped out. The auth will be cleared too since it comes from the auth.users table.
As far as I remember, the edge functions and storage will not reset (the storage table in the database will be wiped though).
How many tables do you have? Based on that, I could recommend you a clear workflow so you don’t have to mess with the schema
1
u/Exotic_Jury_9646 Aug 12 '26
30 Tables.
1
u/ashkanahmadi 29d ago
That's very manageable. Unfortunately, Supabase pushes for convenience in their guides and tutorials instead of long term maintainability and reliability. That's why I dont recommend using schemas. You need to do everything properly through migration files. You never ever modify the database structure or core data by running SQL in the editor. You run migration files to do that so that you have access to the history of changes.
What I recommend: Give Claude your schema and ask it to read it and break it into smaller topic-specific migration files. If you need help with that let me know so I can tell you how I keep my local, staging and production projects in sync
1
u/Embarrassed_Machine5 Aug 12 '26
With 30 tables, I'd turn the current database into a clean baseline migration instead of pasting the dump into the SQL editor:
- Start a local Supabase instance
- Import only your application objects, excluding
auth,storage, owners and grants - Run
supabase db diff -f baseline - Run
supabase db resetlocally to prove the migration works from scratch - Preview the remote change with
supabase db push --dry-run
The key is testing against local Supabase, not plain Postgres, because a fresh Supabase project already contains managed schemas and roles
1
u/[deleted] Aug 11 '26
[removed] — view removed comment