Thanks, yes, that's a dangerous get-and-set situation. Problems already arise with a single put (with outdated values). However, counter columns cannot be reset. CAS style updates (as @rubanm proposed) seem to be unsupported on counter columns. The question the developer of the client has to decide upon is to identify the needed operations for his store. Here we can trade off well running put operations (CassandraStore) vs well runnnig merges (CassandraLongStore) which will basically boil down to using counter columns or not (on Cassandra's side a column family can only contain counters xor "standard" columns). An idea could be to delete the counter column, but this is also unreliable (according to the docs) @rubanm A possible consistent implementation would probably be to not use counters at all and only do CAS-style updates with Cassandra 2.0+ and while loops (but of course this is somehow inefficient (active waiting)). Maybe we can provide both implementations as options, what do you think? Hm. Probably we would be better off if counters could be reset reliably...