Because you're using the ORM to do selects. I'll give you an example: prisma has a "find/findMany." As part of the build process it should examine your usage a

Because you're using the ORM to do selects. I'll give you an example: prisma has a "find/findMany." As part of the build process it should examine your usage and put indexes in the column that you're using in find/findMany Indexes are an implementation detail - but to use RDBMSs successfully you need indexes. ORMs try to hide those implementation details, but without those kinds of details you get bad performance. Prisma just fixed another problem it had with transaction isolation levels. To even understand the problem you need to understand SQL, how databases work, and how each database implements that. It's another important implementation detail that's abstracted away...until it bites you in the ass. Prisma also finally allowed you to use database-specific types instead of just using varchar(191), which was its default for strings. I'm picking on prisma because I happen to be using it right now. There are good things about it, like the way it does migrations and handles schema changes. But there are times its abstractions get in the way, like when you're trying to do aggregated group by (which is easier in SQL than it is in prisma). And its migrations often fail, and to understand why you really need to understand SQL. Hibernate was worse, because it provides a transparent object-level backing store.