Static Cache Control affects the http headers for Cache-Control. As in the case, the server offers intermediate caches that the maximum age = 3600.
Varnish, Rack-Cache, Squid and others actively cache the generated content on the server. The database call is expensive, and even if the request does not make a call in db, the less infrastructure you need to request, as a rule, the faster it will be.
Rack :: Cache is a rack middleware that supports HTTP compliant caching. Their frequently asked questions page contains some useful information about the pros and cons of other caching solutions. Here is a question comparing the rack :: cache for varnish on the hero . Rails also has ActiveSupport :: Cache, which handles fragment and page caching. I'm not sure what the differences are, but both are included in Rails by default. I said earlier that rack :: cache was not defaulted, but I was wrong.
Lac, Squid, and others exist outside the Rails stack in front of the web server (e.g. Apache / Nginx / etc) as a separate process. They are highly customizable, application independent and have some additional features (e.g. Squid ACLs). Varnish and others have the advantage of minimizing the infrastructure that a request must go through in order to gain access. If it is fresh, the request falls into varnish and is immediately returned to the client. This is likely to be most beneficial for high traffic sites and may be excessive for small applications.
Here's an article on heroku detailing the use of rack :: cache in Rails3 . There are also some good railscasts for doing page / fragment caching in an application and using memcached as a backend (which is very important). For varnish and others, you can start with this tutorial on the varnish site .