I'm in the process of investigating different ways of managing very large numbers of rows in a single table. There are a number of solutions, including using native database partitioning or splitting the storing of the data among a runtime configurable number of tables. The data stored in the table is volatile i.e. lots of inserts, deletes & updates being performed, hence the need to be able to reduce the amount of data stored in a single table.

The native database partitioning means we are reliant on 3 different vendor's implementations (DB2, Oracle & MS-SQL), the maintenance of three different schemas and any limitations there-in.

With regards to splitting the data across multiple tables, does Hibernate support this?

At the simplest you have a single class that holds some data (resulting in 1 or more rows). Each instance of the class is to be stored into, at first, a single table (specified in a configuration file). Not a problem. However, due to the amount of data being generated the user wishes to start storing the data across three tables, including the original. These tables can be called anything the user wishes (but must contain certain columns) and can be located anywhere (same database or a different database or server).

We now have three identical tables across which instances of the class are to be stored. Which table an instance goes into is determined by a unique value that each instance has, for example MOD’ing the unique value with the number of tables available. For example, instance 1 goes to table 1, 2 to table 2 and 3 to table 3.

Can the tables that these instances are mapped to be dynamically altered?

IMO it is better to use DB native partitioning.
You may do some creative stuff in H but result might be less than convenient.