Your hunch about "depends" seems right. To me it's really a matter of optimization. You don't want to
SELECT * FROM table
if you're only going to use data that would have been better limited by adding a WHERE clause in your statement. Furthermore, SQL is better at handling data in databases, so beyond the situation with subselects, SQL is going to perform better in those other situations unless your Perl code does some wicked tricks, in which case, will you share?

Notice that I left out subselects as a special case. This in my opinion, is the one type of query mentioned that I think could be handled capably by both Perl and SQL. Of course, it holds true to the "depends" hunch, in that Perl would only be more capable if the single SELECT queries were significantly less complex than the case of using a sub-select statement.

Parsing-wise and other operations with text, Perl will win hands down, but looking at scale, the larger the returned dataset from an SQL query, the more load you throw at Perl. So, then you're looking at hardware issues.

Perl can win, but only if your Perl code is optimized and your SQL isn't. Disclaimer: I haven't run any tests to see if I am right, but the only fair test would be to use identical machines (or the same machine for both the perl and the DBMS) in order to fairly test based on code. But after working with the DBI and numerous databases for a year, I just go with what will provide an adequate response from the application. My reply shows what I tend to do in my own code, and in the past, others familiar with the DBI have reviewed my code favorably.

I'll finish by saying that short of trying every variation, you may not find a decent answer. There are optimization tricks in perl, the DBI, and SQL that will all be handy, and as such, it's not an easy question.

ALL HAIL BRAK!!!