Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.
I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff.
It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning.
Nothing can help you much if the fundamentals are wrong.
I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.
I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback).....
Once things are pretty stable, do a prototype, address any oversights, do the real thing.
It's not rocket science.
If it prototypes well, then further refine it with ER diagrams for future maintenance.
Why is planning everything without validation better than above?
That doesn't mean spending months planning. It does mean doing your best to plan over a few days, then prototype, review, and start implementing. If things change, you now have a clearer idea of the issues and can better address them.
The worst thing you can do is go into development both blind and without important tools you need to make sure that requirements are met--- tools like check constraints, referential integrity, and the like.
large changes? throw away and start over; tools like Rails can help you get up and running really quickly.
I rarely see people go back and fix the mess.
Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand.
Django/South just auto-generates them which removes a huge chore from the daily development workflow.
