So all-in-all, leaving to scope to clean up is okay?

I've recently seen some '99' MySQL errors, which after a little googling appears to be related to too many TCP connections, strange that a script was hitting this limit and not the mysql connection limit first, but I digress.

I've attempted to use Apache::DBI in the past to keep persistent connections but it caused more headaches at the time, so I've always steered clear, and we'll be moving to Fast::CGI/Lighttpd soon anyway, what's similar in a fastCGI env?

I think I'll stick with letting Perl's scope do the work of disconnecting, thanks for making me feel a tad more relaxed in doing so.

When this "active avoidance" makes any difference, I wonder if a connection pooler isn't preferable, e.g. skype's pgBouncer (postgres).

(I haven't measured/benchmarked.)

That depends on your use case. In general, in Perl, I would not advise connection pools.

For mod_perl the standard architecture is to use a pre-fork model with a reverse proxy in front to avoid wasting the time of the expensive mod_perl processes. In this model it generally makes the most sense for each mod_perl process to have one (and only one) database connection to your main database server. In this design a connection pool would have to be maintained outside of mod_perl, and adding one requires another rpc layer of overhead. This represents a lot of work, with little benefit.

The classic place where a connection pool makes sense is in a multi-threaded program where only a fraction of the threads need access to a database handle at any given time. In this architecture a connection pool is much cheaper to implement, and the rewards are more obvious. However threading in Perl is heavy enough that I would not advocate using this architecture for Perl.

The other place where a connection pool makes sense is when you've reached the point where your database is maxing out its capacity. Then you'll want to consider tricks like sharding your database, and maintaining connection pools for accessing each shard. Based on my past experience, I would not expect you to need to go there at below a million dynamic pages an hour. (Though before then you may think you need to go there, when what you really need is to tune your app and database.)