Right now, for a new table to use tablets instead of vnodes, its keyspace must use the network topology replication strategy and the replication option initial_tablets, e.g.,

CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor': 1, 'initial_tablets': 100}

In Alternator the user can't supply this option on CreateTable operation, so Alternator tables always get the old vnodes, and can't use tablets.

We could imagine creating a table with vnodes and then using CQL ALTER KEYSPACE to switch it to tablets, but switching from vnodes to tablets on existing table is not supported, so this won't work. We need a proper way to control whether or not an Alternator CreateTable operation uses tablets for a new table.

I think the easiest and perhaps best solution is to decide that Alternator always uses tablets on new tables, but only if they are available and enabled in the cluster (e.g., currently it requires enabling an experimental feature).

Two other more elaborate options:

1. We can set a global option configuration, e.g., alternator_use_tablets, which controls whether or not Alternator uses tablets.
2. Maybe we can (ab)use the new DynamoDB API TableClass (Alternator: support new table attribute "TableClass" #10431) to say on each new table creation whether it should use vnodes or tablets.

Beyond the UI, we'll need to fix the implementation. Creating an Alternator table with GSI probably not work currently with tablets, because the tablet implementation added a before_create_column_family() notifier that is supposed to be called when creating a table to create its tablet, and it is called for the base table in prepare_new_column_family_announcement(), which we call in create_table_on_shard0() (executor.cc), but we don't call any such function for the view we may also create - so most likely we'll get an error like in #16194. This is why I added the "materialized views" tag to this issue.