The idea is that there are a number of complicated tradeoffs that must be made when designing a schema. See [0] for an example; note that every rule comes with

The idea is that there are a number of complicated tradeoffs that must be made when designing a schema. See [0] for an example; note that every rule comes with an immediate caveat. The result is that you have to be an expert to come up with a great design for a particular system. Even then, if your workload is complex, you might miss a non-obvious choice which will outperform your manual selection. The goal of NoSE is to automate the process by estimating the cost of executing a workload against a wide range of schema designs. We can then select the one which is likely to perform the best. As far as data migration, moving from a relational database is a reasonable use case. Some of the work I'm doing right now is looking at how you can transition between different schemas in a denormalized database. However, our initial use case was to build something that would allow a non-expert user to design a good schema. [0] http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/ http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeli...