Originally from the User Slack
@AndresAndres**:** 
I am looking to create some new tables that keep track of daily counts for certain events, such that the date is part of the partition key but not the entire key. I have a couple of questions about counter tables though:
- Given that counter tables cannot define a TTL, what would be the recommended way to not have an ever-increasing disk usage for counter tables? Would having an scheduled “clean up” job that does a table-scan to delete old unused partitions be the way to go?
- Since counters tables are not yet available for tablet-enabled keyspaces, how easy is it to migrate data from a vNode keyspace to a tablet keyspace? Would it be a question of creating a new keyspace + table and then doing a full-table scan to copy the data over or is there an easier more foolproof way?
- Given that data is never manually deleted, but it is very often updated within a day, would it count as a candidate for TWCS, or would the frequent (within a day) updating make it worse than if we just went with the incremental compaction?
@Botond_Dénes: 2. We are still looking into how to implement vnode → tablet migration. New keyspace + migration is one of the options we are looking into. We will try to make it as easy, foolproof and have as little impact on workloads as possible.
3. Do not use TWCS on a table which doesn’t have default TTL.
@Andres**:** 1. Do you have an opinion about how to delete counter
2. Good to know you are all looking at a strategy to make migrations easy, I am assuming that’s still a bit far off though?
3. 
@Botond_Dénes: 1. Cleaning up unused partition via delete sounds good.
2. We are working on the migration, but it is a major effort, I think it is months away at the least.
That said, the upcoming 2026.1 release will have counter support for tablet keyspaces, see https://github.com/scylladb/scylladb/commit/9208b2f317e3402e733e9deeaa7b67ac500c31d3.
GitHub: cql3: allow counters with tablets · scylladb/scylladb@9208b2f