Is it specified somewhere that all driver implementations must be thread-safe?

This comment explains the rationale:

arrow-adbc/rust/core/src/driver_manager.rs

Lines 93 to 102 in c6e1ab5

	// According to the ADBC specification, objects allow serialized access from
	// multiple threads: one thread may make a call, and once finished, another
	// thread may make a call. They do not allow concurrent access from multiple
	// threads.
	//
	// In order to implement this semantics, all FFI objects are wrapped into
	// `Mutex`. Hence, we need to deal with multiple locks at once, so care must
	// be taken to avoid deadlock and in particular we must avoid "lock inversion".
	// The general convention chosen here is to first acquire lock to the driver
	// and then acquire lock to the specific object under implementation.

The driver classes: database, connection, statement, reader... are a whole different story. The driver itself is a static struct of function pointers that once initialized shouldn't be changing.

Requiring a lock on the driver for every operation makes ADBC drivers incapable of any parallelism whatsoever.

I have very simple SQL queries taking 3s just because I have other threads in the program running SQL queries. And this number could be much higher (minutes!) if I start running more queries that cost more in multiple threads.

#2715 (comment)

It seems we should update that comment, though.

@lidavidm if you're OK with the comment update, please merge.

LGTM, will merge after CI - thanks Felipe

Should we specify that access to the private fields of the driver

must be serialized by driver (private_data) and driver manager (private_manager) implementations?

Should we specify that access to the private fields of the driver

arrow-adbc/c/include/arrow-adbc/adbc.h

Lines 989 to 996 in c6e1ab5

	/// \brief Opaque driver-defined state.
	/// This field is NULL if the driver is unintialized/freed (but
	/// it need not have a value even if the driver is initialized).
	void* private_data;
	/// \brief Opaque driver manager-defined state.
	/// This field is NULL if the driver is unintialized/freed (but
	/// it need not have a value even if the driver is initialized).
	void* private_manager;

must be serialized by driver (private_data) and driver manager (private_manager) implementations?

I agree. I checked some of the code and it uses these fields only for reference counts (which are atomic).

It would be good to have a comment in adbc.h calling the need for thread-safety on accessing these fields, but there are so many copies of adbc.h around...

There is only one copy. (The others are just synchronized via pre-commit)