Using DBI from multiple threads is (or has been) generally deemed not a good idea because some or all implementations of DBI, and/or the underlying C libraries were not thread safe.

To quote the DBI pod:

Threads and Thread Safety

Perl 5.7 and later support a new threading model called iThreads. (The old ``5.005 style'' threads are not supported by the DBI.)

In the iThreads model each thread has it's own copy of the perl interpreter. When a new thread is created the original perl interpreter is 'cloned' to create a new copy for the new thread.

If the DBI and drivers are loaded and handles created before the thread is created then it will get a cloned copy of the DBI, the drivers and the handles.

However, the internal pointer data within the handles will refer to the DBI and drivers in the original interpreter. Using those handles in the new interpreter thread is not safe, so the DBI detects this and croaks on any method call using handles that don't belong to the current thread (except for DESTROY).

Because of this (possibly temporary) restriction, newly created threads must make their own connctions to the database. Handles can't be shared across threads.

But BEWARE, some underlying database APIs (the code the DBD driver uses to talk to the database, often supplied by the database vendor) are not thread safe. If it's not thread safe, then allowing more than one thread to enter the code at the same time may cause subtle/serious problems. In some cases allowing more than one thread to enter the code, even if not at the same time, can cause problems. You have been warned.

Unless you are using a new version of DBI, and the above paragraph has been updated, you should not share db handles across threads. At best it will fail early and obviously. At worst it will run, but give you mixed up or corrupted data.

It is certainly safe to run overlapping queries concurrently from different processes, so the limitation lies within the libraries/implementation, rather than inherently with threads.

However, if the parallelised queries are against the same DB and/or tables, then there may be little benefit derivable from running them concurrently, as the RDBMS may need to serialise them at the DB end.