What do you mean with a "single DB cluster"? I don't know much about the cu_changes table, but as far as I know there is one table per wiki (where it is enabled)
If you just need to add a new field to the current table (on each wiki) you'd need to follow the schema change procedure: https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change
Please allow enough time for the schema change to happen (it can take up to months, depending on how big the table is).

In T212781#4848941, @Marostegui wrote:

What do you mean with a "single DB cluster"? I don't know much about the cu_changes table, but as far as I know there is one table per wiki (where it is enabled)
If you just need to add a new field to the current table (on each wiki) you'd need to follow the schema change procedure: https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change
Please allow enough time for the schema change to happen (it can take up to months, depending on how big the table is).

"Single cluster" meant central DB e.g. "centralauth.cu_changes" @s7 cluster

Thanks for clarifying that!
So one big table holding the data for all the wikis is probably not a good idea as you'd be creating just a big massive table.
I am also not sure about having one table per section as you mentioned: s3_cu_changes as sections can dynamically change, for example s3 gets new wikis by default, and those get created relatively often ie: T207095 T210762 T212625
We also move existing databases between sections to balance load ie: T184805

Probably the approach of selecting each table from each db is easier to scale and to manage (as nothing needs to be changed). What you might want to do is to optimize those queries to make them run as fast as possible. And maybe review the indexes in case you need new ones to satisfy your possibly, new queries?
Reminder: We don't mind (to a certain extend) if you make many queries, as long as they are fast. What can bring down databases are slow and complex queries :)

So one big table holding the data for all the wikis is probably not a good idea as you'd be creating just a big massive table.

Just FYI, these tables are purged every 90 days, so table size stays relatively constant. Currently the table on enwiki has ~12 million rows.

In T212781#4849240, @Bawolff wrote:

So one big table holding the data for all the wikis is probably not a good idea as you'd be creating just a big massive table.

Just FYI, these tables are purged every 90 days, so table size stays relatively constant. Currently the table on enwiki has ~12 million rows.

But they are still pretty big, these are the current sizes:

s1: 14GB
s2: 15GB
s3: Around 5GB
s4: 12GB
s5: 1.5GB
s6: 17GB
s7: 12GB
s8: 33GB

That is a total size of around 100GB for a single table (probably a bit less, as it is most likely fragmented) but you get what I mean :-)

Thanks for advice!.

I'll just implement with plan 3. then if we can't wait to show the result, I'll switch to Plan 1.
if we had trouble with Plan 1, I'll switch to Plan 2.