What Is an ORM? How Developers Query Databases Without Writing SQL

Querying Databases Without Writing SQL

Most web apps need to store data. Users, orders, messages, settings — it all ends up in a database somewhere. And databases speak SQL: a structured query language that’s powerful but verbose, error-prone, and a bit of a context switch when you’re writing application logic in JavaScript or Python.

An ORM — Object-Relational Mapper — is the layer that sits between your application code and your database. It lets you query and manipulate data using the same language you’re already writing, without dropping into raw SQL for every read and write. If you’ve ever used Prisma, Sequelize, SQLAlchemy, or Django’s built-in ORM, you’ve used one.

This article covers what an ORM is, how it works under the hood, the real trade-offs involved, and when it’s the right tool for the job.

What an ORM Actually Does

The name is a bit of a mouthful. “Object-relational mapper” describes the core problem it solves: relational databases store data in tables and rows, but application code works with objects and classes. An ORM maps between those two representations automatically.

Instead of writing:

SELECT * FROM users WHERE email = 'alice@example.com' LIMIT 1;

You write something like:

const user = await db.user.findFirst({ where: { email: 'alice@example.com' } });

The ORM generates the SQL, sends it to the database, and hands you back a typed object. You stay in your language. The database gets valid SQL. Nobody has to manually serialize or deserialize rows into objects.

This is especially useful in TypeScript full-stack development, where you want end-to-end type safety. Modern ORMs like Prisma generate TypeScript types from your schema automatically, so the return value of a query is fully typed — no casting, no guessing.

How ORMs Work Under the Hood

At a basic level, every ORM does three things:

Defines a model — a class or schema that maps to a database table
Generates SQL — translates method calls into valid SQL queries
Handles results — maps database rows back into objects your code can work with

Models and Tables

You define your data model in code. In Prisma (a popular TypeScript ORM), that looks like:

model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
}

This definition becomes both a TypeScript type and a database table. The ORM handles creating and migrating the table in the database based on this schema. You don’t write the CREATE TABLE statement — the ORM does.

This is closely tied to the concept of a database schema, which defines the structure, types, and constraints of your data. An ORM essentially lets you manage that schema through code rather than SQL files.

Query Generation

When you call a method like db.user.findMany(), the ORM builds and executes a SQL query behind the scenes. For a filtered query like:

const activeUsers = await db.user.findMany({
  where: { active: true },
  orderBy: { createdAt: 'desc' },
  take: 10
});

The ORM produces something close to:

SELECT * FROM "User" WHERE active = true ORDER BY "createdAt" DESC LIMIT 10;

You get readable, method-chained application code. The database gets optimized SQL.

Migrations

When your schema changes — you add a column, rename a field, create a new table — the ORM can generate a migration file that updates the database structure. Some ORMs do this automatically; others require you to run a command explicitly. Either way, it’s a significant improvement over managing raw SQL migration scripts by hand.

The Most Common ORMs

Different languages have their own dominant ORMs. Here’s a quick map:

JavaScript / TypeScript

Prisma — schema-first, strong TypeScript support, widely used in modern full-stack apps
TypeORM — class-based, supports TypeScript decorators
Drizzle — newer, schema-in-code approach, lightweight and fast
Sequelize — older, widely used, more verbose

Python

SQLAlchemy — the standard for Python, very flexible, supports both ORM-style and raw SQL
Django ORM — built into Django, opinionated, excellent for rapid development

Ruby

ActiveRecord — part of Ruby on Rails, convention-over-configuration, very mature

Java / Kotlin

Hibernate — the original Java ORM, still widely deployed
Exposed — Kotlin-first, growing in popularity

The right choice depends on your language, your framework, and how much control you want over the generated SQL.

ORM vs Raw SQL: The Real Trade-offs

An ORM is not strictly better than writing SQL directly. It’s a trade-off. Here’s an honest breakdown.

What ORMs do well

Less boilerplate. Basic CRUD operations — create, read, update, delete — require far less code. You’re not writing repetitive SQL strings for every query.

Type safety. In TypeScript projects, a well-configured ORM gives you compile-time guarantees about what columns exist and what types they return. Catch mistakes before they hit production.

Schema management. Migrations, table creation, and constraint management happen through code, which is easier to review and version-control than raw SQL files.

Database portability. In theory, you can switch from PostgreSQL to MySQL without rewriting queries. In practice this rarely happens, but it’s a real benefit when it does.

Developer velocity. For standard operations on well-defined models, ORMs are faster to write and easier to read.

Where ORMs fall short

Complex queries get awkward. Multi-table joins with aggregations, window functions, recursive CTEs — the ORM abstraction starts to leak. You either write raw SQL anyway or fight the ORM’s query builder.

Performance surprises. ORMs can generate inefficient SQL if you’re not paying attention. The classic example: fetching a list of posts and then issuing a separate query for each post’s author (the “N+1 query problem”). Most ORMs have ways to solve this (eager loading, include options), but you have to know to use them.

Black box behavior. When something goes wrong, you’re debugging generated SQL, not the SQL you wrote. Adding a logging layer to see what queries are actually running is usually the first debugging step.

Over-fetching. ORMs often return entire objects when you only need a subset of columns. This wastes bandwidth and can cause unintended data exposure if you’re not careful.

The takeaway: ORMs shine for standard data access patterns. They become a liability for complex analytical queries or performance-critical paths where you need precise control over what SQL runs.

When to Use an ORM

Use an ORM when:

You’re building a standard web app with predictable CRUD operations
Your team is more comfortable in application code than SQL
You want automatic schema migrations and type-safe queries
You’re working in TypeScript and want end-to-end type safety (Prisma is excellent here)
The database is backing a REST API with defined resource endpoints

Use raw SQL (or a query builder) when:

Your queries are genuinely complex — heavy analytics, reporting, or multi-table aggregations
You’re working with a legacy schema that doesn’t map cleanly to ORM models
Performance is critical and you need precise control over index usage and query plans
You’re already comfortable with SQL and find the ORM abstraction gets in your way

Most production apps use both. ORM for standard operations, raw SQL or a query builder for the complex stuff.

ORMs and the Abstraction Ladder

ORMs fit into a broader pattern in software development: every useful tool is an abstraction over something lower-level. SQL is an abstraction over storage engines and disk I/O. An ORM is an abstraction over SQL. TypeScript is an abstraction over JavaScript. This is just how the stack works.

The abstraction ladder from assembly to TypeScript to spec is a useful frame here. Each layer trades control for productivity. You give up some visibility into what’s happening underneath in exchange for writing less code and making fewer mistakes at the level you care about.

ORMs sit comfortably in the middle of that ladder for database access. They’re not magic — they’re a code-generation layer with opinions. Understanding what they generate (and when those opinions are wrong) is what separates developers who use them confidently from developers who get surprised by performance issues in production.

ORMs in the Context of Full-Stack Apps

If you’re building a full-stack app — frontend, backend, database — the ORM lives in the backend layer. It’s the component that the backend uses to talk to the database. The frontend never touches the ORM directly.

A typical flow looks like this:

User submits a form
Frontend sends a request to an API endpoint
Backend receives the request, validates the input
ORM translates the operation into SQL and runs it against the database
Database returns rows; ORM maps them into typed objects
Backend sends the result back to the frontend

The ORM handles step 4. Everything else is your application code.

Most modern backend frameworks have a preferred ORM. Next.js projects often use Prisma. Django apps use Django ORM. Rails apps use ActiveRecord. If you’re setting up a managed database for a web app, the ORM is one of the first decisions you’ll make after picking the database itself.

Speaking of databases: many modern ORMs work well with SQLite for development and lighter-weight production deployments. Prisma, TypeORM, and SQLAlchemy all support SQLite out of the box, which makes local development fast and dependency-free.

How Remy Handles Database Access

In Remy, you don’t configure an ORM — it’s already wired in. When you describe your app in a spec, you define what data your app needs, and Remy generates the backend, database schema, and typed access layer from that description.

The database is SQLite (with WAL journaling and automatic schema migrations on deploy). The backend is TypeScript. The data access layer is generated to match your spec exactly. You’re not picking between Prisma and Drizzle or writing migration files by hand.

This matters because the hidden cost of wiring up your own infrastructure — configuring the ORM, writing migrations, connecting it to your backend, managing connection pools — is real. It’s not glamorous work, and it’s easy to get wrong in ways that cause problems in production.

When the spec is the source of truth, the data model, the schema, and the access layer all stay in sync automatically. You describe what data the app works with; the system figures out how to store and retrieve it. The generated code is readable TypeScript — you can inspect it, extend it, or drop to raw SQL when you need to.

If you want to build a full-stack app without wiring all of this up yourself, you can try Remy at mindstudio.ai/remy.

Frequently Asked Questions

What is an ORM in simple terms?

An ORM (Object-Relational Mapper) is a library that lets you read and write database records using your programming language instead of SQL. You call methods like user.save() or db.post.findMany(), and the ORM generates and runs the SQL for you. It also maps database rows back into objects your code can use directly.

Do I need to know SQL to use an ORM?

Not to get started, but yes to use one well. Understanding SQL helps you recognize when your ORM is generating inefficient queries, how to use raw SQL for complex operations, and why certain operations are slow. Developers who only use an ORM and never look at the underlying SQL often run into performance problems they can’t diagnose.

What’s the difference between an ORM and a query builder?

A query builder (like Knex.js) gives you a programmatic way to construct SQL queries — still thinking in SQL terms, just with method chaining instead of string concatenation. An ORM goes further: it manages the schema, the object mapping, and often the migrations too. ORMs are higher-level; query builders give you more control over the generated SQL.

Is Prisma an ORM?

Yes, Prisma is a TypeScript-first ORM. It uses a schema file (in Prisma’s own schema language) to define your data model, generates TypeScript types from that schema, and provides a client for type-safe database queries. It also includes a migration tool. It’s one of the most widely used ORMs in modern TypeScript and Node.js projects. If you’re using TypeScript for backend development, Prisma is usually the first ORM worth evaluating.

Can ORMs cause performance problems?

Yes. The most common issue is the N+1 query problem: fetching a list of records and then making a separate database query for each item to load related data. Most ORMs solve this with eager loading options (like include in Prisma or eager_load in ActiveRecord), but you have to opt in. Another common issue is selecting all columns when you only need a few — most ORMs let you specify which fields to return (select in Prisma), but the default is often to return everything.

What ORM should I use for a TypeScript project?

Prisma is the most popular choice and has the best TypeScript integration. Drizzle is worth considering if you want something lighter-weight with a more SQL-like API. TypeORM is another option, especially if you prefer class-based models with decorators. For most new TypeScript projects, start with Prisma — it has the best documentation, the largest ecosystem, and first-class support in most full-stack frameworks.

Key Takeaways

An ORM lets you query and update a database using application code instead of SQL — it generates the SQL for you and maps results back into typed objects.
The core components are: a model definition, query generation, and result mapping. Most ORMs also handle schema migrations.
ORMs trade SQL control for developer productivity. They’re excellent for standard CRUD operations and less suited for complex analytical queries.
The N+1 query problem is the most common ORM performance pitfall — know how to use eager loading.
In TypeScript projects, Prisma is the dominant ORM choice because of its strong type generation and migration tooling.
The right choice of ORM depends on your language, framework, and how much control you need over the generated SQL.

If you want to skip the ORM configuration entirely and go straight to building something real, try Remy — the database, schema, and data access layer are generated automatically from your app spec.