Tables in Cassandra should be designed according to the required query patterns. This is important to do, in order to ensure the queries can be served by a single node. However, this requires a balancing act to ensure that the required amount of query flexibility can be met. In Cassandra, typically one table is designed to serve one query. If you require the data to be consumed by additional queries, it is usually advisable to store it redundantly with a primary key designed to match the new query.

Of course, managing multiple tables essentially containing the same data can be cumbersome and subject to inconsistency. Thus it is recommended to keep the number of query tables relatively small (low single digits). Cassandra does allow the creation of secondary indexes, but these are horribly inefficient in clusters with a large number of nodes.

Therefore, applications requiring multiple, dynamic, or ad hoc queries should avoid using Cassandra. This includes applications requiring search-engine capability, reporting, or business analysis. Some similar edge cases may be made to work in Cassandra, but, by and large, there are other tools that are better suited to provide that functionality.