[sigseg1v]

Totally agree, it needs a careful balance. But is it possible to know when to use what?

Anecdote: A couple years ago I migrated a 1M+ LOC application from one database to another, cutting the cloud hosting costs practically in half. This was absolutely massive for the company. It took a bit less than a year, but was possible because the people who designed the application didn't write any hardcoded queries, and everything went through an ORM or a query builder. Everything was built to an interface, even though they all only had one implementation. This turned out to be absolutely critical when we had to add the second implementation (and because we needed to maintain compatibility for the original implementation at the same time due to some one-off contracts) and the migration would not have been worth it cost-wise if the proper architecture wasn't in place from the start.

Now take the same application. It has tons of complicated architecture stuff implemented in house. Parts of it are definitely overengineered. It's been apparent when doing other upgrades and finding out "oh... this doesn't work because it's using a custom JSON serializer" that the choice to do that was poor.

In the end, I think the right choice for that application was the complex design that allowed those big migrations. For others, they might never do that and only get hit with downsides.

What it needs is likely a good vision and someone smart to know what to abstract and what to not abstract such that it will have been a good choice 15 years down the road.

[mobiuscog]

ORMs and query builders can also constrain the implementation from a performance and flexibility perspective though.

Your anecdote and reflections are all absolutely true in my experience, but I've found just as many problems with off-the-shelf ORMs.

The key is the clean boundaries/interfaces and keeping things simple - leaving the bridge intact so that your enemies may retreat.