Thanks for regurgitating how RethinkDB works and completely ignoring my concerns. And thanks for intentionally spelling my name wrong even though I signed as "Joe" and you saw this. How disrespectful.
To everyone else in the world,
I am not satisfied with Michael's response. I clearly anticipated exactly what he would say.
1) Under successful conditions, the server will ultimately need to queue those millions of records to be consumed by the client anyway. So I'm ok with that. One would just need a way to mitigate without dictating the performance of the success case. I offered a solution to keep pressure minimized while more or less removing the demand to have the client ask for a continue update on every response. I did this before Michael even responded.
2) Michael describes a serialized client consumption design, which espouses my concerns entirely. The reason I [had to] build my own rethinkdb driver is because the official drivers are asychronous but NOT CONCURRENT, which means they do not lend to multithreaded and parallel processing design patterns. If I request a query or a changefeed with a certain response size I want to process those responses concurrently as fast as the server can dish them out. As the client, I shouldn't have to care if I've I received or finished processing any other responses associated with the query. Anything else is just a waste of time and will never be as performant as a database service implementation that understand this.
If a client has to keep asking for changefeed updates then a true subscribe pattern it is not. I didn't want to believe it until now, but it's no wonder RethinkDB is getting its ass kicked in this regard by relational implementations such as Postgres.