H2 vs. HSQLDB vs. Derby | In-memory RDBMS for Reporting APP

I am developing a Data REST API for dynamic reporting. Basically, you pass data to it (along with data manipulation functions) and it returns you HTML with functions applied to the data. Typically, these functions will filter, group, group, sort (which would suggest a regular DBMS). I am thinking about using an in-memory DB for this. In doing so, I am simply using the functions offered by the DB instead of implementing myself.

However, this requires the service to load data (possibly bulk load) and then run a series of queries built dynamically - as part of each service call.

The data (input) to be loaded into the database can be no more than 100 thousand rows. Certainly not millions!

But different streams can be available to the service (each of them will load their data into the database and read at the same time). Of course the jdbc connection will be merged and tables truncated at the end of each transaction.

I ask myself, what am I going overboard and trying to use in-memory dbs? I myself have used (and often heard) about in-memory dbs (especially H2 and HSQL) only in the context of integration testing.

It would be interesting to hear your opinions.