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.

Better is relative. Ecto is different than ActiveRecord in a number of ways, though. The most important is that Ecto does not follow the Active Record pattern. It’s closer to the Unit of Work or Repository pattern. Everything else flows from this difference. Simplifying a bit, ActiveRecord is a map, a true object wrapper, that exposes a data store by mapping it directly to a Ruby class. Ecto doesn’t care much about whether or how your schemas relate to the underlying data, or whether you even have a schema or use a changeset. It’s a broad query language that talks to data structures, not just a data store.

So the advantage is one of developer happiness I suppose. There probably isn’t any real benefit to one over the other for most things. Ecto can be said to provide more flexibility, but that would also come with the cost of more responsibility. Rails can feel more “magical” because things (usually) just work but maybe they also work sooner and provide more feedback to the developer. Bottom line: AR and Ecto both solve the same problems in very different ways. The further you go down the road with one or the other, the more divergent they will feel. Whichever of them feels more natural or comfortable for you is probably the one that’s better.

Ecto is written in elixir and it would be really hard to use active record in an elixir project since active record is written in ruby .