It depends a lot on the project. I think learning SQL and basic database theory are a strict requirement. ORMs are a great tools to help make life easier, but y

It depends a lot on the project. I think learning SQL and basic database theory are a strict requirement. ORMs are a great tools to help make life easier, but you'll need to reach in sometimes in order to fix performance bugs. I've learned to love both. ActiveRecord is amazing. It makes it really easy to get stuff up and running, and it works for a wide range of problems. There's nothing better for typical CRUD operations, especially when you models map mostly 1-to-1 to your tables. You start to encounter problems later on as the application grows, especially when you have lots of associations, complicated queries, or your models grow too fat. Maybe your problem isn't really with ORMs, but with MVC or whatever application architecture you're using. For example, Rails has been criticized because of its fat models and its overall "flavor" of MVC. Trailblazer [0] was created by a Rails critic as an alternative approach for structuring your web application. I won't go into the details, since the website already does a good job explaining. But he effectively kills the traditional model and shifts the persistence layer around, which is a fairly common pattern. I remember reading book that discussed ASP.NET's approach to MVC. I don't quite remember all the details, but it mostly amounted to having four primary layers (presentation, application, domain, infrastructure) which were further divided and given specific responsibilities. This approach is overly verbose and complicated for some cases, but the abstractions appear to make more sense as the application increases in complexity. A small example is an application in which you have to break up a model's data between multiple storage services like Redis and the RDBMS. You'll probably like Ecto [1]. It's an ORM for Elixir. After the 2.0 rewrite it's a lightweight embodiment of some of the concepts mentioned above. One of the key insights is that you'll want to separate business logic from data and presentation. But it really depends on the project! It might help or it might just add more boilerplate. [0] http://trailblazer.to http://trailblazer.to [1] https://hexdocs.pm/ecto/getting-started.html https://hexdocs.pm/ecto/getting-started.html