Just trying to understand what way is best.

As usual, please define "best".

If you want top performance, you should let the webserver and the operating system cooperate to handle delivery of images, so that sendfile() and similar functions can be used, ideally delivering the file directly from the buffer cache to the network card without any additional copying (zero copy). Also, you don't need much code inside your program. All HTTP features automatically available (Ranges, If-modified-since, ETags, ...). Disadvantages: content delivery happens mostly outside your control. Access control must be handled by the webserver.

If you want total control, pipe the image through your program, where you can do custom access checks, post processing, and so on. Obvious disadvantage: Much code, either in your program or in a fat framework. Even more code if you need all HTTP features.

When you do not use the web servers file delivery mechanisms, you are free to choose where to store your images. The filesystem is often easier, most times also faster than the database. But if you want atomic updates, rollbacks and transactions, it is very hard to store images outside the database.

Often, database and webserver are located on different machines, so the connection between database and webserver can become a bottleneck. This setup is quite common for "cheap webspace".

Sometimes, even the filesystem from which the webserver delivers content is located on a dedicated fileserver (NFS or similar), so that can be a bottleneck, too. This setup is common when you need to run several web servers in parallel behind a loadbalancer or in a DNS-based round-robin setup.

Regarding URL rewriting: DON'T, if you want maximum performance. Avoid any work that is not absolutely needed, both in the webserver setup and in your program. If you need to protect images from unauthorised access, pipe those through your application or use the webserver's access control methods. Leave the images not worth to be protected (decoration elements, background images, ...) in a directory directly served by the webserver.

Regarding CGI and mod_perl/mod_perl2: mod_perl is way faster than CGI, but it runs inside the Apache process. This may be a security risk, and a single bug can take down the entire webserver. FastCGI allows you to run your application inside a separate process, with separate privileges if you like, and if your application crashes, it does not kill the Apache. FastCGI is persistent like mod_perl, but it does not mess with Apache's internals and allows you to switch to a different webserver quite easily. And of course, FastCGI is much faster than an ordinary CGI, but it may be a few percents slower than mod_perl, depending on the setup.

Alexander