If I remember correctly all drivers implement streaming atop of the pull n feature introduced with bolt 4.0.
The issue with the transport code is that until neo4j 5.0, the server would buffer small records and emit packets only when the buffer was filled. Then, when they rewrote the server code (with netty I believe) they ditched the buffering and started emitting packets for each record, regardless of the record size. This is a known issue that will affect all drivers, according to them, it’s not much of an issue in real life scenarios since records would typically be larger (details Potential performance regression in neo4j 5.x with bolt, maybe linked to buffering · Issue #13045 · neo4j/neo4j · GitHub ). When, writing the driver that means, unfortunately, that it’s pretty much impossible to write code that consumes records efficiently for every scenario (basically if you were to set active once for each packet, with small records, you’d do it in a very tight loop leading to really bad performance).
Regarding streaming, m_bolt does support the pull n feature, but it doesn’t concern itself further with it (this will be handled at the neo4_ex level). m_bolt being inspired by mint, there is a way to receive records (by the calling process), which means it’s possible -in theory - to process records as they come. The issue here is that records should only be considered final when they’re followed by a success message, meaning that implementers of higher level drivers using this feature will need to be careful. In any case those won’t fix the issue with large amounts of small records.
Edit : the numbers provided in the github issue aren’t meant to compare drivers performance.
