How to scale with MySQL (when not ready to scale properly)
PARTITIONing does not save space.  Each partition has 4M-7M of "free" space.  That can add up.  Partitioning can be used for removing data from the server (or moving to another server) "old" data.  More discussion:  http://mysql.rjweb.org/doc.php/partitionmaint

Nor is any ad hoc partitioning likely to help.  That is splitting tables up, moving between databases (I'm talking about CREATE DATABASE, not server) will not change performance, nor space.  On the other hand, "easier for backups / exports" may be a valid reason.  Please provide details so we can discuss.

"Sharding" is complex, but it is the way to split data across multiple servers.  (Note: I am using "server" to mean a separate physical machine.)

A small fix is to shrink the datatypes in tables.  Are you using BIGINT (8 bytes) when MEDIUMINT (3 bytes) would suffice?  Etc, etc.

Summary tables are an excellent way to save space and speed up "reports".  But perhaps they are not as small as they could be?  Let's see SHOW CREATE TABLE.

"growing fast I was thinking into splitting it into XX tables" -- NO, NO, NO!  The only exceptions is when "sharding".

How do you populate the Summary Table(s)?  Some tips:  http://mysql.rjweb.org/doc.php/summarytables  I assume your summary tables are updated either in realtime, or nightly?  And you update them only incrementally, not by starting over.

You say 1 insert per second?  That is a very low rate.  Perhaps it is faster than that?

When the data is properly indexed and/or summarized, the size of the table does not matter (for performance).  Are you concerned about disk space or speed?