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.)