Code

You mention:
"We'll be completely redesigning field storage in CB 3.x though to eliminate any field limitations."

When is the anticipated release of CB 3.x?

No idea. We'll be starting CB 3.x development this year and slowly rolling it out. It will primarily start as just an independent application layer as we plan to expand CB to WordPress and eventually standalone. Field storage rewrite probably won't happen until a little ways into CB 3.x where we'll be moving field storage to a separate table and 1 row in that table per user field, which will eliminate storage limits.

Thanks Kyle!

I am going to try to reduce the database row size.
I need some advice - I'm not that good at knowing how to figure the size of a field type.

From reviewing the database, it looks like Radio Buttons are stored as text and single Checkboxes are stored as tinyint.
I can change over 30 Radio Buttons to single Checkboxes.

Do you think it will make a difference in the row size?
Is that is a good place to start before eliminating fields I'd like to keep? 
Next fields I would eliminate would be Editor Text Areas - does that also make sense?

Thanks for your help.

Our field types are basically already using as small of a column type as they can. Ideally you should review your current setup and see how it can be improved and reduced.

I can change over 30 Radio Buttons to single Checkboxes.

Do you think it will make a difference in the row size?

That won't likely make a meaningful impact. Your issue is you've just too many fields for your MySQL configuration.

Is that is a good place to start before eliminating fields I'd like to keep?

The best solution to keep everything you have is to simply change your database configuration. This should be as simple as adjusting innodb_page_size in your MySQL config file. Sometimes this can be done from phpmyadmin if the config file is writeable. The below documentation explains this further.

dev.mysql.com/doc/refman/8.0/en/column-count-limit.html