ORM

A relational database speaks SQL and stores data in rows and columns. Your application speaks objects: a User has a name and an email, an Order has a total and a list of items. An ORM sits between the two and maps tables to classes, rows to object instances, and columns to fields. That mapping is where the name comes from.

Instead of writing SELECT * FROM users WHERE id = 42, you write something like User.findById(42) and get back a User object. Instead of building an INSERT statement and remembering the column order, you create an object and call save(). The ORM generates the SQL, sends it over the database driver, reads the result rows, and hands you back typed objects.

Popular ORMs cover most languages: SQLAlchemy and Django ORM for Python, Hibernate and JPA for Java, ActiveRecord for Ruby on Rails, Entity Framework for .NET, and Prisma, Drizzle, and TypeORM for TypeScript. They differ a lot in style but solve the same core problem.

You start by declaring models. In Prisma you write a schema file; in SQLAlchemy or Django you write Python classes; in Drizzle you write TypeScript objects that describe each table and column. The ORM uses this definition both to validate your code and to know how to build queries.

When you call something like db.query.users.findMany({ where: { active: true } }), the ORM builds an abstract query, compiles it to a SQL string with bound parameters, and sends it through a connection from a pool. Parameters are bound separately from the SQL text, which is why ORMs give you protection against SQL injection almost for free.

Many heavier ORMs (Hibernate, SQLAlchemy, ActiveRecord) also track loaded objects in a session or identity map, batch changes, and flush them as a transaction when you commit. Lighter query builders like Drizzle skip most of that and stay close to the SQL you would have written, trading magic for predictability.

Most ORMs also ship migrations. You change a model, generate a migration file that holds the ALTER TABLE statements, and run it to evolve the schema in a versioned, repeatable way across dev, staging, and production.

Use an ORM when you want fewer hand-written queries, type safety between your code and your schema, and easy migrations. For standard CRUD work, an ORM removes a huge amount of boilerplate and catches mistakes at compile time rather than at runtime in production.

The classic trap is the N+1 query problem. Loop over 100 users and access user.posts inside the loop, and a naive ORM fires 1 query for the users plus 100 more for the posts, 101 round trips where a single JOIN would do. You fix this with eager loading or explicit joins, but you have to know it is happening.

The other trade-off is the leaky abstraction. ORMs hide SQL right up to the point where you need a window function, a recursive CTE, or a finely tuned index hint, and then you drop down to raw SQL anyway. Good ORMs make that escape hatch easy. The honest guidance: let the ORM handle the 90 percent of simple queries and write raw SQL for the hot, complex 10 percent.

Say you run an e-commerce app on PostgreSQL. With raw SQL you would write a parameterized INSERT for every new order, manually map result rows back into structs, and update column lists by hand every time the schema changes.

With an ORM like Prisma you write prisma.order.create({ data: { userId, total, items } }) and it generates the INSERT, runs it inside a transaction if items span multiple tables, and returns a fully typed Order object. Change the schema by editing the model, run prisma migrate, and the generated client updates its types so a forgotten field is now a compile error.

Shopify runs on Rails ActiveRecord at enormous scale, and Instagram runs on the Django ORM. Both prove an ORM can carry a serious production workload, as long as the team watches query counts and reaches for raw SQL on the few queries that need it.