> most applications won't ever reach the scale where it's a better investment to ditch the ORM
Aside from working in a large application that used ORM (and had many, many problems because of it), my personal experience with using them - specifically Hibernate - to develop an application from scratch was based on a relatively simple application to parse and help reconcile bank statements. This was never going to be an application that required "scale".
What I found was that, relative to just using SQL, the ORM version of my application was much more complex, required significantly more knowledge of the tools, and produced inferior code.
While I was able to get an MVP up and running slightly faster with the ORM, the productivity benefits diminished - and rapidly became negative - while the performance of the application for even a single user was very poor. Eventually, what should have taken milliseconds in SQL was literally taking seconds in the ORM. Not only did it generate stupid queries, each query had much greater latency. And what I was doing was extremely simple.
In addition to the poor performance and greater complexity, ORMs - like all dependencies - are not cost-free. There can be a significant learning curve just to get started with an ORM like Hibernate, and that learning curve then needs to apply to all developers who touch the code base.
In our larger application, we found that hibernate specifically had so many edge cases - not to mention its own SQL syntax - that the overhead of using it came to dominate the development time for new features. The need to create multiple objects (database entities AND entity objects) that could get out of sync, problems with cache consistency, latency, HQL... the list of gotchas and principle violations (DRY, KISS, SRP) was endless.
These days I simply refuse to use ORMs, and tend to do any complex database work in the database itself, i.e. with plpgsql. I find working directly with SQL to be insanely productive, and the resulting code to be in the order of 10x - 100x faster than what I used to be able to achieve in Java using ORMs.
> The really basic stuff can get you really far without exposing you to vendor-lock in or yak shavings
In my experience, vendor lock-in and yak-shaving are exactly what you get with ORMs.
Aside from working in a large application that used ORM (and had many, many problems because of it), my personal experience with using them - specifically Hibernate - to develop an application from scratch was based on a relatively simple application to parse and help reconcile bank statements. This was never going to be an application that required "scale".
What I found was that, relative to just using SQL, the ORM version of my application was much more complex, required significantly more knowledge of the tools, and produced inferior code.
While I was able to get an MVP up and running slightly faster with the ORM, the productivity benefits diminished - and rapidly became negative - while the performance of the application for even a single user was very poor. Eventually, what should have taken milliseconds in SQL was literally taking seconds in the ORM. Not only did it generate stupid queries, each query had much greater latency. And what I was doing was extremely simple.
In addition to the poor performance and greater complexity, ORMs - like all dependencies - are not cost-free. There can be a significant learning curve just to get started with an ORM like Hibernate, and that learning curve then needs to apply to all developers who touch the code base.
In our larger application, we found that hibernate specifically had so many edge cases - not to mention its own SQL syntax - that the overhead of using it came to dominate the development time for new features. The need to create multiple objects (database entities AND entity objects) that could get out of sync, problems with cache consistency, latency, HQL... the list of gotchas and principle violations (DRY, KISS, SRP) was endless.
These days I simply refuse to use ORMs, and tend to do any complex database work in the database itself, i.e. with plpgsql. I find working directly with SQL to be insanely productive, and the resulting code to be in the order of 10x - 100x faster than what I used to be able to achieve in Java using ORMs.
> The really basic stuff can get you really far without exposing you to vendor-lock in or yak shavings
In my experience, vendor lock-in and yak-shaving are exactly what you get with ORMs.