Are most people using prisma migrate for managing schema changes and outside db features? Or are you using products like flyway or something else? We have the need for a good bit of stored procedure management and a few other things that might be pushing what we should do in prisma.

Hey Jonathan 👋, If I understand correctly customizing migration file is becoming an overhead for you? Creating a new migration version for every stored procedure changes is not working out for you?

well I think it will work but the more I think about it, it seems like there is an opportunity prisma could take advantage of in this area. So hear me out… this is a little deeper issue with most migration tools out there. 1. Traditional “migration” tools like “Flyway” always add a versioned migration & this is how it completely runs. Which is how the customized migration in prisma works. But where Prisma differs is the schema file and the shadow db to do a diff. This works great. 2. Database Project tools like VS DB Projects (which have some major issues), some others, create file structures for their schema/table/trigger/stored proc structure. Prisma is managing “tables” like this essentially in the

prisma.schema

but nothing else. I am saying it would be nice to be able to structure things like stored procs in a similar method.

I totally get what you are trying to say, I’ll convey this message to our engineering team to get their views on this and check how could this be implemented.