I think fetch direction can safely be ignored. after looking again at spec. this is a hint to the driver, which has no visible effects during runtime (i.e ResultSet.next() will still move forward, and previous() will move backward). We cannot use this hint - to move backwards with ResultSet.previous(), we have to read and cache the whole result, no way around it.

+1 for solving this issue....
We run into a similiar problem while reading a large set of data from a MariaDB and were forced to switch to the streamed mode, since we ran into OutOfMemory exceptions when fetching all records at once (~8m records). Other JDBC drivers (like Oracle) only fetch the records, when iterating over the result set and therefore require a lot less of memory if the records are processed in a loop and then discarded.
It would be great to support a configurable fetch size instead of force the user to decide wether to read all or nothing.

Some good news Paolo : that's in the roadmap for next version 1.4.0.

bazzip ,alas, is no principal difference between streamed mode and configurable fetch size. streaming mode requires least memory though
Are you unhappy to be "forced" into this mode?

@Diego very nice to hear!

@Vladislav
Two issues with the streamed mode

• We use shared java code which is executed on both MariaDB and Oracle databases (some kind of data replication). The fetch size is set for each statement according to business logic and expected statement result size. With this setup we run into OutOfMemoryException problems with large data sets and the MariaDB JDBC driver, since the driver tried to load all data into memory. We were forced to implement a "if oracle then use fetchSize else use Integer.MIN_VALUE" Hack to solve the problem
• I would expect a performance gain using an adequate fetch size instead of the streaming mode, which requires a JDBC driver <-> database server network round trip for each fetched result row

I agree on portability, but I doubt you will gain any performance

the driver does exactly the same amount of network reads, and the server the same amount of writes.
The server writes whole result set, the client reads the whole result set, Oracle may and actually does perform very differently.

This is now implemented on version 1.4.0.

Like Vladislav say, since all datas have to be read, performance doesn't change a lot,

JMH results (source https://codeshare.io/OlBRO) when streaming 100,000 rows

Bench.fetchSizeBy1000 : 50.274 ± 0.206 ms/op (read with fetch size 1000)
Bench.fetchSizeAll : 50.593 ± 0.252 ms/op (read all data)
Bench.fetchSizeOneByOne : 51.641 ± 0.299 ms/op (fetch one by one)

No big difference, but avoiding to create a big buffer permit to gain a small 1%, ( and avoid loading all in memory)