=pod L, you L about L performance. Even without benchmarking you could have L, that Class::DBI is quite slow. Fortunately there are some alternative object-relational mappers available in the perl universe. The best ones I found so far are L and L. I took a closer look at both and would like to share my experience. As L shows, RDBO is faster than DBIC in most of the case. The generated SQL doesn't differ too much and therefor it must be the perl side of things that makes the difference. Matt S Trout says: However, RDBO achieves its perl speed by aggressive inlining of stuff etc. - for example the main object retrieval function in RDBO's manager class is >3000 lines in a single sub. DBIC values extensibility over a few extra sub calls, so methods are much more broken out and there are many more ways to hook into the DBIC execution process to extend. Also its idea of resultsets is something I really love. Here's a small example to illustrate that: lang:Perl my $user_rs = $schema->resultset('User')->search({ registered => 1 }); $user_rs = $user_rs->search( { comment.title => 'Foo' }, { join => { 'article' => 'comment' }, order_by => 'user.name', }, ); # no sql executed yet. # now you can use your resultset as an iterator or query a list # of User objects from it or .. while (my $user = $user_rs->next) { ... } # or my $count = $user_rs->count; Using these resultset makes it extremely easy to built up queries piece by piece and to work together well with, for example, a templating system. You don't need to fetch all row-objects and give them to your template. You can just pass the iterator to the template library. There's a lot more to say about this two object-relational mappers (for example RDBO supports prefetching of multiple one-to-many at once, which DBIC doesn't), but maybe you just should take a look yourself. I personally prefer DBIx::Class for its vast extensibility. =cut