Frankly, absent profiling tools, I think testing both solutions has merit.

With profiling tools, the answer will likely become obviously with little to no core code change.

And were I a betting man, I'd say both solutions are likely to produce improvements, with a smaller bet that multithreading would likely yield a greater gain in the scrapes/minute category. Improving the back end (DB updates/minute) can only be a good thing, so I am inclined to favor doing both in any regard.

But the multi-threading scraper into a queue with a single-threaded DBI operation sounds like the more fun engineering exercise (and I admit this should be an irrelevant attribute in the decision making process but I had to throw it out there).

Encapsulating DB updates in transactions is almost no development effort at all (and highlights that it should probably be done anyway).

How's that for sitting on the fence?  :-)