This is Bill @rethinkdb The distinction between query.run(conn) and conn.run(query) is very fine indeed. There has been much discussion about this and there ar

This is Bill @rethinkdb The distinction between query.run(conn) and conn.run(query) is very fine indeed. There has been much discussion about this and there are both solutions have their merits. At one point we even supported both but decided the simplicity of having only one solution merited dropping the other. Creating a new connection involves opening a TCP connection and sending a message to validate the driver to the server, altogether a few round trips. There is a small bit of per connection state stored on the server but since RethinkDB uses a custom coroutine implementation for concurrency support this does not amount to the overhead of an independent OS thread for each connection. Invoking the query with a specific connection object is thread safe. There is a feature designed to help REPL users that stores the last connection in global state that is slated for removal in the upcoming release (1.4) that is obviously not re-entrant. It would make sense to have connection pooling, especially in the python driver where connections block on requests. This is an idea we're exploring but is lower down on the priority list. As it is a fully client side feature there is nothing stopping 3rd party driver developers from implementing a solution though the official drivers will have to wait for other priorities.