Hacker News Reader

How do you handle schema changes after your project is in production?

I mean, sure start with a unified schema file until you have a production release... deploy, populate with placeholder data, etc... but once released, having a file for each set of changes isn't a bad thing.

Also, the management tools you can have single files for each view/sproc, etc... it's just schema migrations you need to take care of.

View on HN

Make a PR that edits the .sql file, deploy to staging, deploy to prod. Git tracks changes to the file, and your CI should be aware of what commit it's on. (If you even have CI)

This only works if you don't care about being able to auto roll back DB changes without making a new commit, cause Postgres doesn't have a declarative DDL.

I'm more fond of just number+label files and a simple log as deployed to prevent re-run scenarios... Grate/Roundhouse does that for me... I don't use all the features, just separate each sproc/view and the up directory of migrations. This is checked into source control and gets deployed with the services themselves.

Reply on news.ycombinator.com