Creating a new perl process for every message is more resource-intensive in some ways, not in others.

First off, all the SMTP-handling code is in C. That's got to be less resource-intensive than perl. Second, it's already written, most bugs worked out, and someone else will fix any new bugs found. That's less resource-intensive than writing it yourself (you are a resource, too). Third, spawning off a new perl process, compiling and then running a bunch of perl code (both a .pl and a bunch of modules) is really not that resource-intensive. The only really expensive part here is the DB connect, which you can mitigate with FastCGI or DBD::Proxy if it really becomes a problem (premature optimisation--). Oh, and by using qmail, you get the preforking done for you. No, your code isn't forked - but if multiple emails come in at the same time, qmail will kick you off multiple times, providing with better scaling without any thought or design on your part. That, too, makes it less resource-intensive (again, you're a resource). And spewing the message over a pipe (purely in RAM, remember) is trivial - we're talking about copying a couple of KB around (usually). That's not resource-intensive at all, especially considering perl already does that type of work when you pass around scalars instead of references to scalars.

Personally, I like the "use qmail or postfix" solution as a starting point, as it allows you to focus on the real work you're trying to accomplish (stuffing a database) without worrying about stuff you don't really care about (SMTP, preforking, dropping privileges, etc.). If it turns out that you need more, you can always go back and try cleaning up whatever bottleneck there really is, whether that's a db connection or it's the fork/exec overhead, or something else. But to solve performance issues you may never have is really wasting resources: you.