Not a java developer myself, but as a longtime coder and even an author of an ORM I can relate. I think ORMs just bridged that gap of “how my objects look in c

Not a java developer myself, but as a longtime coder and even an author of an ORM I can relate. I think ORMs just bridged that gap of “how my objects look in code” and “how to store them” quite well. But lately we’ve been removing a lot of the reasons to use ORMs altogether. By using more functional languages and features, we’ve been getting rid of that “O”. By adding more relationship features to databases like jsonb in postgres, and even nosql dbs themselves, we’ve been removing the “R” bit as well. There’s simply a log less for ORMs left to do in modern codebases. I’ve personally been using only raw sql with some help for building complex queries - in the JSX way of embedding stuff into the query as opposed to query builders that build it altogether, and couldn’t be happier. With migrations handled by a separate library, all the db connection lib has to do is handle pools and run queries. I’ve been looking into software that would statically type the sql queries themselves, which could end up as a way better dev experience. ORMs helped there too by giving you some piece of mind that what you wrote was correct with regards to the DB schema, but that was only true if no other tool touched your db. But that is very hard for sufficiently large systems, especially in the era of microservices. With typed sql queries it’s no longer necessary, and is even safer.