Yes, that is precisely what the AGPL means. If you have some proprietary web application that is the user of RethinkDB that your users connect to instead, then no, since the modifications are only used internally by you.
The goal here is to prevent SaaS-ification of AGPL'ed applications, if you host an application under the license and make it available to others you can't hide your changes just because the users aren't directly installing the binaries.
> If my build system sucks (and most build systems do suck), am I legally liable for not providing a working build script that a third party can use, even if every patch I have is in a public bugtracker?
The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
> In the same way, it's entirely reasonable for organizations to determine that for a specific use case, both simple permissive licenses and GPL-style licenses are fine, but AGPL-style ones aren't.
If you're trying to make money off the backs of GPL'ed software by making modifications to it and then throwing it behind a service so you don't technically have to redistribute your changes then, yes, you should be wary of the AGPL. You should also feel ashamed of yourself.
That being said, there's some projects licensed under the AGPL that have given me pause, like GhostScript. I've had to yank that out of projects, because even though they are used internally-only, we are linking to the code which means the project as a whole becomes AGPL licensed. Things like MongoDB/RethinkDB are non-issues since they are only being accessed over the network, the client can be licensed under whatever they damn well want.
