What if things don’t go wrong?

One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement.

But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions.

Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”

The biggest deal for me is type safety (I use C#'s EntityFramework). While composing the ORM queries, I get the benefit of static verification, autocompletion, and can avoid the common boilerplate of joins. When reading code, find-references and so on work.

Do people actually use ORM to avoid writing SQL (there are other patterns for that), or do they use it because it saves writing the boilerplate of object hydration?

It is a more efficient way to data analysis, SQL is just one way, Java is another way, and ObjectiveSQL, instead of using Java instead of SQL, let's forget about SQL