ORM

Almost every app stores data permanently, meaning the data persists even after the app is closed. For this, it usually relies on a database: a storage system that organizes information into tables with rows and columns. But a program doesn’t think in tables. It works with so-called objects, meaning data packages like “user Anna, 15 years old, email address X”. ORM is the mediating layer between these two worlds. It automatically converts objects into table rows and table rows back into objects.

Why developers don’t want to talk to the database directly

Without ORM, you have to formulate database commands yourself. The language for this is called SQL and looks quite different from typical program code. A developer then constantly jumps back and forth between two ways of thinking. Experts call this friction the “Object-Relational Impedance Mismatch”, meaning the incompatibility of two data models.

An ORM therefore saves time above all. Instead of typing twenty lines of SQL, you write a short command like “save this user”. The rest happens in the background. In large projects with hundreds of tables, this difference is enormous.

A second advantage is security. A well-known form of attack is called SQL injection: an attacker smuggles their own database commands in through an input field. Good ORMs treat user input strictly as plain text and never as a command. This largely eliminates one of the most common security vulnerabilities.

The translation between object and table row

First, you define which class belongs to which table. A class is the blueprint for objects, for example a template “User” with the fields name and age. This template is mapped to the table “users”, field by field. This assignment is called the mapping, hence the name.

When the program then calls a function, the ORM generates the corresponding SQL command behind the scenes. The database returns rows, and the ORM builds finished objects from them. The developer sees nothing of this intermediate step. You can think of it like an interpreter at a conversation: both sides speak their native language and still understand each other.

A common misconception is to assume ORMs are always faster. The opposite can happen. Notorious is the N+1 problem: you load a list of 100 posts and then query the author for each one individually. That’s 101 requests instead of a single one. Experienced developers therefore check which commands their ORM actually generates.

From web shops to AI applications

ORMs are found in almost every larger web application. Well-known representatives are Hibernate for Java, Django ORM and SQLAlchemy for Python, as well as Prisma for JavaScript. Anyone reading a job posting for software development will regularly find these names in the requirements list.

AI products also use ORMs, though unspectacularly in the engine room. A chatbot service has to manage accounts, billing, and conversation histories. The language model itself has nothing to do with this, but the app surrounding it certainly does. Currently interesting is a new trend: AI assistants are now writing ORM code themselves quite reliably.

A warning about the abbreviation: in business news, ORM often stands for “Online Reputation Management”, meaning the maintenance of a company’s reputation online. This has nothing to do with databases. Which meaning is intended is almost always revealed by the context.