I can totally understand your point of view as I also share it and
taking the decision to migrate from the default AR to another
solution was not that easy as you might expect.
I found that MongoDB is better supported by the Rails community than
Sequel, so I had to write some integration code by my own, like the
sequel-devise gem. And I had to look at the source code of Devise as
it wasn’t clearly documented what such an adapter should provide and
it took some time, but not that much as you could expect. I’ve also
had to add a “save!” method to Sequel::Model for being able to use
FactoryGirl and a few other adjustments but I wouldn’t say it was a
pain to get my preferred tools (like RSpec) to gracefully integrate
to Sequel, although it certainly took some time.
I've wrote about some of the solutions I've written, but I'm
planning to post some more interesting features when I find some
Among the features I haven't written about yet are the possibility
of running my development (or any other) environment inside a
transaction inspired by the “rails c --sandbox” option.
But actually the "--sandbox" is half-baked while my solution is not:
Other than that I was able to use transactions and PostgreSQL
savepoints even in RSpec beforeAll/afterAll hooks, which I just
can’t do in out-of-the-box RSpec + AR setup.
Using transactions this way is not supported by Sequel as RSpec
doesn’t provide an aroundAll hook, but I could get fast and great
support from Jeremy Evans, the current main maintainer of Sequel. He
helped me to get an unsupported solution that would help me with the
sandbox and transaction support in beforeAll/afterAll.
This not only made my integration specs run much faster (truncate is
real slow in PostgreSQL for testing purposes and transactions are
much faster then lots of DELETE statements that must be issued in a
certain order due to foreign key constraints). It also made my specs
easier to read.
And running "SANDBOX=1 rails s" is really helpful when I'm
experimenting with a new feature or trying to reproduce a bug and
have a copy of the production database that I don’t want to mess in
my development environment. So every single change would be rolled
back when I hit Ctrl+C. This is awesome.
Of course, I have only tested this on PostgreSQL which also happens
to be the database vendor of choice of most Sequel users,
differently from AR that seems to be better target at MySQL. I don’t
know if MySQL would support savepoints, so maybe my solution won’t
fit everyone’s need.
But this is another reason why I chose Sequel. I don't like MySQL
and I don’t think AR gets some things right. For example, Sequel
thinks that the database should be used in full, with ACID support
and that your constraints are very important. It also encourages to
write triggers when appropriate among other things. And I’ve always
shared those same ideas. This was always something I disliked in AR
and how it doesn’t seem so much worried about such constraints in
the sense that you write “t.references :something” and it won’t
create a foreign key to it as well as an index. At least it is how
it has been over the last years. And I think this happens because
the original authors prefer MySql and in the last years it bundled
with MyISAM engine set to the default and this situation has just
changed this year.
This tells me a lot. For example, in my humble opinion, it shows me
that the original authors didn’t know about databases as much as the
database expert people I admire. Or they wouldn’t have chosen MySql
in the first place. Also it tells me that they don’t care about
database constraints, indices and transactions as much as I do. It
seems that they started writing something and when they got more
clients and the queries got slower they realized that they should
create an index, for example. Maybe I’m just guessing here, but this
is definitely not the way I see databases.
Sequel just seems more aligned with my own ideas and even if I had
to take some time to adapt it to the gems I’m using (Devise,
FactoryGirl, RSpec) I can say it totally worthed my little time
spent on this integration and it has saved me a lot of work trying
to figure out how to do some tasks with AR, specially when you can’t
find much documentation about it.
I'm not advocating everyone should replace AR with Sequel. It will
really depend on what project your ideas are more aligned with. I
can say that Rails itself integrates very well to Sequel, although
you might have to write some code to integrate to other gems. And I
don’t think it would be likely to break your application due to some
Rails upgrade because Sequel would be no longer supported as it
doesn’t require any integration to Rails itself.
But such decision is up to you and I'd advice you to spend some time
reflecting on it for your next project because the ORM is a key
library in most applications, specially usual web ones.
I'm not currently considering using anything other than Sequel for
any serious new project I decide to create and can take this
decision. If you decide for Sequel though, just let me know if you
need any assistance and I’ll gladly help you. You can also send any
questions to sequel-talk and it’s likely that you get a response in