Could you also provide some "gut feeling" on what you think about multi-threaded database-apps

If your proposed concurrent accesses to the DB would be accessing the same tables, then those accesses would most likely get serialised at the DB anyway, so you will likely not see much gain from the concurrency. And potentially you may suffer degradation. This is true regardless of whether you achieve the concurrency through, threads, processes or event loop architectures. It is also true whether you use Perl or C or Java.

Whether there is any gain to be had from using threads as a part of a DB app will depend if there is anything else in the application that could usefully be processed whilst you are waiting for the DB to do its thing.

If, for example, you need to perform some calculations on one set of results, whilst quering the next set: using a thread to perform those calculations whilst the main thread waits for the results of the next query has the potential for benefits.

Likewise, if you are retrieving data for insertion from a disk or the network, then overlapping the insertion of one batch with the reading of then next batch can increase throughput.

The thing to remember is, if your multi-threaded app only communicates with the DB via one thread, then it does not matter if the DB libraries are thread-safe, because from the point of view of the DB, your app looks and acts like a single-threaded application.

Given that, and the fact that there is rarely any gain from accessing a DB concurrently for a single application due to the inherent serialisation that occurs at the DB itself, the "trick" to successfully exploiting threads in a DB application is to get away from your natural instinct to want to have multiple threads talking to the DB.

Instead, consider how to partition the processing so that your application can be doing something useful whilst it is waiting for the DB to fulfill your requests. One key to efficiency, is to query your results, or post your updates, in smaller batches to strike a balance between the time taken to prepare updates or deal with results; and the time taken to send or recieve them.