How do you decide between Mojo::Pg or DBIx::Class (or modern forks of the latter)?

[ajmetz]

I thought this was a general Perl question, rather than Mojolicious specific, so posted it on the PerlCommunity facebook group, and so far, I have only had answers with DBIx::Class insight rather than Mojo::Pg insight. So thought I'd cross post the same post here too.

https://www.facebook.com/groups/498667124274252/?multi_permalinks=2282812599193020

=====

Do you have advice on when to use DBIx::Class esque modules with Mojolicious or the Mojo::Pg inspired modules?

DBIx::Class has traditionally been popular, and DBIO ( https://metacpan.org/pod/DBIO ) or other new forks (Chad's talk coming up today - https://tprc.us/tprc-2026-gsp/schedule-2/ ) may take it forwards.
I haven't used it enough to know what the pros and cons are versus using something like Mojo::Pg

I have of course heard of Mojolicious plugins that can act as glue between DBIx::Class and Mojolicious. So I know some mojolicious framework users, stick with DBIx::Class, and that makes sense if they've come from Catalyst that seemed always paired with it.

I'm just wondering - are these equivalent tools ( and you can use one or the other equally ), or, if I'm coding an app, am I going to need one over the other, in certain circumstances - much like in OOP - Moo will do for most use cases, and then some more complex use cases things may require Moose. Are there use cases where one is preferable over the other?

So how do you decide when architecting a new webapp in mojolicious - if you'll be using DBIx::Class or one of the Mojo::Pg-inspired modules (Mojo::Pg/Mojo::SQLite/Mojo::MySQL)...?

[christopherraa]

At $work we used to have everything in DBIx::Class, and to be honest I think it was very comfortable to work with. Relations (including many-to-many / one-to-many etc) are handled well, the interfaces are neat and the documentation is good. The community on IRC has been excellent as well.

That said, we've been slowly and surely migrating away from DBIx::Class. The reasons for this are multiple:

• Mojo::Pg has become really, really good.
• Performance is harder to maintain and improve with DBIx::Class
• Using tools such as DBIx::Class hides what is going on (big one!)
• We use Mojo::Pg anyway since we do a lot of Minion-related stuff

So even though the usage of DBIx::Class looks super pretty it is in our opinion better to use Mojo::Pg. The item saying that DBIx::Class hides what is going on is kind of a big deal to us. We feel that it is important to build a solid understanding internally of both our data model, what drives performance positively, how queries should and should not be constructed etc. This is most easily done by exposing the queries in the code.

Where the queries are simple we usually use the convenience methods that builds on SQL::Abstract in combination with Mojo::Collection, so we run code such as

my %customers = $db->select(customers => ['id', 'name'])
    ->hashes
    ->map(sub { $_->{id} => $_->{name} })
    ->each;

in the imaginary scenario of needing to build a simple customer id to customer name lookup.

Do note that you don't have to choose to not have a kind of a model system. It is not uncommon to have helpers that makes it so that you can have DBIx::Class-looking code for the simple tasks. As an example can

$c->customers->find($customer_id)->delete

be achieved by defining a helper customer.find that does the select from the customer table and instantiates the entry as a MyCorp::Model::Customer either manually by having the helper be something like

$app->helper('customers.find' => sub ($c, $id) {
    my $customer = $c->pg->db->select(customers => '*', { id => $id })->hash;
    return unless $customer;
    return MyCorp::Model::Customer->new(%$customer);
});

You could even go a step further and use the role system to add functionality to the collections that Mojo::Pg::Result return so that you can do

$c->pg->db->select('customers')->hashes->as('Customer')

This sort of brings me to what we love about Mojolicious: the framework is put together in such as way that you get to decide what works for you, your team, your org etc. Want it super simple? You get that out of the box. Want a lot of convenience for the developers acting as simple consumers? You can have that too.

❤️ Mojolicious ❤️

[davorg]

You're comparing two rather different tools that sit at different abstraction levels, so I don't think it's quite an apples-to-apples comparison.

The Mojo::Pg family are essentially lightweight database access libraries. They give you convenient access to the database and make it pleasant to execute SQL from a Mojolicious application. SQL remains the primary abstraction.

DBIx::Class is an ORM. It models your database as a set of Perl classes with relationships, reusable queries and domain logic. SQL is still there when you need it, but much of the time you're working at a higher level.

So I don't think the decision is "which is better?". It's "what level of abstraction do you want your application to work at?"

Personally, I've been writing SQL for nearly forty years and I'm perfectly happy doing so. I still generally choose DBIx::Class because I find it a more powerful tool. I like having row objects, relationships, composable resultsets, inflation/deflation, and the ability to encapsulate common queries and business logic in one place instead of scattering SQL throughout my application.

There are downsides, of course. DBIx::Class has a steeper learning curve, there's more machinery involved, and you need to understand what SQL it's generating if you care about performance. It's certainly possible to write inefficient DBIC code[*]. But in my experience the productivity gains on any non-trivial application more than outweigh those costs.

If, on the other hand, your application is relatively small, your data access is straightforward, or you want to make full use of PostgreSQL-specific features by writing the SQL yourself, then Mojo::Pg is a perfectly reasonable choice.

So for me it isn't really a Mojolicious question at all. If I'm building an application that would benefit from an ORM, I'll use DBIx::Class regardless of whether the web framework is Mojolicious, Dancer2 or something else. If I just need a lightweight SQL layer, then something like Mojo::Pg is a good fit.

[*] I spent some time last week optimising the DBIC queries that generate the front page of https://lineofsuccession.co.uk/. In a few hours work, I got it down from 500+ queries to about three. It's still DBIC, but it's now well-optimised DBIC :-)

[ajmetz]

For further reading, Dave has gone on to blog here: https://perlhacks.com/2026/06/choosing-the-right-database-abstraction/

[ajmetz]

Both of your answers are insightful and very helpful - thank you!

I loved @christopherraa's use of map and each, and looked through some of my code to see if there was an opportunity to refactor anything based on that. The point that using Mojo::Pg doesn't stop you from introducing some ORM stuff too, via helpers (in my work in progress code I've attempted this via classes, with helpers as loose glue to the classes) was/is appreciated too, =).

@davorg - you've provided great insight. Yes, I have a work in progress project where I've both used Mojo::SQLite and then created my classes and methods for the model ( https://github.com/ajmetz/management/tree/develop/project/lib/Management/App/MVC/Model/Database ). I suspect this is me doing manually what a command to create a DBIx::Class schema from a table might do ( DBIx::Class::Schema::Loader !? ) - except I am too inexperienced to know, and that's why I ask questions, and am looking forwards to Mohammad's DBIx::Class book, as well as seeing if the DBIO fork from Torsten or the fork Chad may have shown off in his headline Perl Conference talk yesterday, become a new future for DBIx::Class (did anyone here attend the conference and know what was said/discussed?).

After looking up DBIx::Class::Schema::Loader I also went back to the Mojo::Pg perldoc, and found in the "Growing" section, there's stuff about building your own classes, and using them via a plugin/helper.

I think whether something is the right tool for the job depends on how well it aligns with your goal, and we risk talking at crossed purposes if we have different goals.

My goal currently, is to find out the best way to go about making a website or webapp, and have that foundational knowledge, or even reuseable code, ready to go/use whenever I have to quickly create a website or webapp... Ideally implementing best practice from the start, so when additional stuff if required, there isn't a massive need for refactoring. That said, I am aware of counter arguments - such as - you ain't gonna need it, and refactor-as-you-grow, etc.

Hm. Now had a little browse of https://github.com/davorg/succession/commits/master/ - looking at the order imposed on Model.pm commit and others.

[guest20]

If you do end up doing exactly what DBIx::Class does and building a nice consistent well factored schema with sensible class names and helpful methods, the worst crime you'll have committed is writing some code... Which isn't so bad, really

[VectorPeak]

The useful dividing line is whether you want SQL to be your main interface, or whether you want a schema/resultset layer to become part of your application architecture.

For a Mojolicious app, Mojo::Pg is a very good fit when the database access is relatively explicit: route/controller/service code asks for data, you write the SQL, and you get back rows. It keeps the mental model close to PostgreSQL, plays nicely with migrations, JSON, LISTEN/NOTIFY, transactions, and generally doesn’t make you translate every database feature through an ORM abstraction.

DBIx::Class-style tools make more sense when the relational model itself is a large part of the app: lots of relationships, reused query fragments, authorization or business rules that naturally live near resultsets, prefetching related objects, complex create/update flows, or a team that benefits from a shared schema API instead of everyone writing SQL slightly differently. At that point the extra layer can pay for itself.

The trap is treating them as interchangeable persistence backends. They aren’t quite that. With Mojo::Pg, your application tends to own query structure directly. With DBIx::Class/DBIO, the schema layer owns a lot more of the vocabulary of the app. That can be great, but it is also a commitment: debugging, performance tuning, onboarding, and dependency risk all move partly into that layer.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆