Well, as I mentioned, I had already decided to use Template Toolkit and Log::Log4Perl, so I'm glad you recommend them.
DBI is lower level than I'm looking for...it is pretty much the lowest level at which it is sane to write DB code in Perl, and my goal is to be well above that level. (To go any lower you'd need to shell out or write XS to a driver--which is effectively what the DBD modules do.) The reason I chose Tangram is because it means that, for a certain category of DB interactions (object persistence) I can completely ignore the DB.
Thanks for the reminder about Class::DBI; I'll compare/contrast it against Tangram.
I'm echoing perrin here - DB access is typically 80-90% of the time to process an HTML request. C::A is actually nicely optimized and is very light. If you're worried about speed, I'd seriously look at CDBI over Tangram - I think it's lighter, which may improve performance somewhat.
In general, if you think something isn't in Perl, try it out, because it usually is. :-)
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
Saying CDBI is more lightweight than Tangram, is like saying that DBI is more lightweight than CDBI.
Of course it's more lightweight, but it doesn't provide any real abstractions. CDBI is just another SQL macro library; it just happens to be the most actively developed. It's a very good alternative to raw DBI.
There is a large class of problems for which Tangram can solve easily, and CDBI just has no solution at all. For instance, with Tangram it is very simple to build up "complex" queries without resorting to hacking SQL. Likewise, if you're retrofitting to existing database schemas, Tangram can seem awkward and inept.
However, for building large scale database driven applications from scratch, my personal experience would say that using Tangram in concert with Class::Tangram gives you the most flexibility and adaptability of any currently available database abstraction for Perl 5.