[pbiggar]

Good questions!

We haven't decided on transactional consistency yet - if there are particular goals there, I'd love to hear them. Ostensibly, we want to allow users to design the right distributed system for themselves, and provide ways of saying "we want this DB to prioritize availability over consistency", for example. But we haven't yet decided how to do that or what to support at launch, nor where the bounds of a transaction will be.

We have a DB migration tool. The DB has a current type, and you specify the new type, and add rollforward and rollback functions. That creates a new name for the datastore: any use of the old name uses the old type, and the new name uses the new type (both on the same datastore, applying rollforward and rollback as necessary for the interface you need). Once you've removed all the references to the old name, you mark the migration as complete, and we'll handle the underlying transformation of the data behind the scenes.

[shalabhc]

I think operation level consistency policies are more useful than DB level. For instance, saying bounded stale reads are OK for some operation could be useful for the high read scenarios and hopefully the system will materialize a cache.

[pbiggar]

Gotcha. Yeah, we're planning on allowing users to tweak their performance by providing this sort of constraint to the system, and allowing the system optimize it. We are far from that, but that's where we're aiming for.