Databases vs. everchanging model

This sprint I've been struggling hard to postpone the creation of a database to back up WCF service operations 'till next sprint. Last sprint I've insisted on keeping the store of service objects in memory - so the service loses all data upon restart. This was enough to make an iteration (and I think it was a good decision) but a lot of people on the team pushed back.

The reason I don't want a database from day 1 is our domain model is undergoing such changes that it would have taken us an entire sprint redesigning the database for every change, if we had decided to go down that road. We've spent that time on useful things instead, I hope.

Last week we, again, came to a point where a decision was needed on whether to create the database or not. And once again I pushed back, so we've chosen to save all data into a single file (having more than one would require extra work for reconstructing object references) using plain old data contracts. A question came up though: how do you save all those different collections of domain model elements preserving object references between those collections? The answer to that was dumping all objects into a List<object>, creating a DataContractSerializer around it (with exactly that type - List<object>), feeding to the serializer a list of known types made of all types of contracts (note that it's no longer domain model elements) that are used to store the state of the service, telling the serializer to preserve object references. Of course, all of this would still be hard to do (because of reference fixups), if we had not decided to use data contracts everywhere for the state of the service - as opposed to domain model objects we had in sprint 1.

Note that this is a temporary solution, we will migrate to a database at some point. That said, I suppose modifying data contracts is slightly easier than modifying the database -- I may be exaggerating the complexity of making changes to the databases since I haven't seen any database refactoring tools, and there must be some.

(When putting the reconstructed object graph' elements back to their collections we've iterated thru deserialized elements and added them to appropriate collections depending on the type of element).

Could post the code proving the concept works, if anyone is interested.