Ecto is much more comparable to Hanami’s ORM (hanami-model) than Rails’ ActiveRecord: Both Ecto and hanami-model are based on ideas from Domain Driven Design.

The main advantage of this approach overr ActiveRecord’s is that Ecto Schemas (which are called ‘Entities’ in Hanami by the way), that describe the structure of your datatypes are decoupled from the way they are to be persisted (which are called ‘Repositories’ in both). By decoupling these two concerns, it is a lot easier to re-use and test your entities, as well as keeping them smaller. Also, swapping out one repository for another (for instance for sharding or multi-tenancy applications) is now something that can then be easily done.

The main advantage of the ActiveRecord-way is that it is definitely slightly easier to set up and get up and running with fast. However, in the long run, because for instance it’s reliance on e.g. hooks like before_create or after_save, it is near-impossible to test and maintain your application without strongly coupling everything to the database at all times.

One concrete benefit of the explicit Ecto approach is that it’s very easy to separately query a master vs a replicated database, you just need to use a different repo for each. With ActiveRecord it’s all implicit so you can’t freely switch back and forth.

This is the main design difference in my mind.

• ActiveRecord automagically loads records leading to nasty surprises and n+1 records, ecto is explicit about it
• similarly in ActiveRecord some methods might go to the databse, some may not… it’s on you to know, in ecto you know when you go to the database (when you call out to Repo)
• as mentioned by @Qqwy is that in ecto you pick yourself what the attributes are (your schema) whereas ActiveRecord just grabs everything (which can also hit performance if you have huge columns that you rarely need for instance)
• Ecto is a lot closer to SQL than ActiveRecord - as said before Ecto is not your ORM - which makes translating SQL easier
• Perhaps my favorite thing abut Ecto are changesets as they are use case oriented, meaning I pick and choose which attributes can change and then which validations I want to run as opposed to ActiveRecord where all validations and callbacks are run all the time by default - I just gave a 45 minute talk detailing this problem and having a look at possible solutions
• The one thing I’d put on ActiveRecord’s side: It’s much easier to handle in the beginning. As association are automatically loaded you don’t have to worry about preloading. As it is Repo and schema in one it’s easier to write Article.find(1) than Repo.get(Article, 1). In the long run I highly prefer the tradeoffs/implications of all of these on the ecto side. You don’t have to care about what changeset to use because there is no choice.

ActiveRecord often feels like implicit magic that you need a degree in to handle, Ecto is simpler and explicit which is a definitive win.