Choosing an ORM for Node.js Backends
Object-Relational Mappers (ORMs) bridge the gap between JavaScript code and SQL databases. sequelize, typeorm, objection, and bookshelf are four popular choices in the Node.js ecosystem. sequelize and typeorm are full-featured ORMs with active record patterns, while objection and bookshelf are built on top of the knex query builder, offering a different approach to data modeling. This comparison helps full-stack developers select the right tool for serverless functions, API routes, or dedicated backend services.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
ORM Showdown: Bookshelf vs Objection vs Sequelize vs TypeORM
When building a backend in Node.js — whether for serverless functions, API routes, or a dedicated service — you need a reliable way to talk to your database. Object-Relational Mappers (ORMs) let you interact with database tables using JavaScript classes instead of raw SQL. While sequelize and typeorm are full-featured standalone ORMs, objection and bookshelf sit on top of the knex query builder. Let's break down how they handle real-world tasks.
🏗️ Defining Data Models
How you define your tables sets the tone for the rest of your code. Some tools use classes, others use configuration objects, and some rely on decorators.
sequelize uses a class-based initialization or a define method.
- You specify column types and options directly in the model definition.
- Supports both v6 and v7 syntax styles.
// sequelize: Model definition
const User = sequelize.define('User', {
firstName: DataTypes.STRING,
lastName: DataTypes.STRING
});
typeorm relies heavily on TypeScript decorators.
- You decorate a class to mark it as an entity.
- Columns are defined with type metadata.
// typeorm: Entity definition
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number;
@Column()
firstName: string;
}
objection extends a base Model class.
- You must specify the
tableNameproperty. - It uses
knexunder the hood for query building.
// objection: Model class
class User extends Model {
static get tableName() {
return 'users';
}
}
bookshelf extends bookshelf.Model.
- Similar to
objectionbut with an older API style. - Requires a
knexinstance to be passed during setup.
// bookshelf: Model definition
const User = bookshelf.Model.extend({
tableName: 'users'
});
🔍 Fetching Records
Reading data is the most common operation. The syntax varies from promise-based chains to repository patterns.
sequelize uses static methods on the model.
- Methods like
findOneorfindAllreturn promises. - Options object controls filtering and limits.
// sequelize: Fetching
const user = await User.findOne({
where: { lastName: 'Smith' }
});
typeorm uses a Repository pattern.
- You get a repository instance from the connection manager.
- Methods like
findorfindOneByare used.
// typeorm: Fetching
const user = await userRepository.findOneBy({
lastName: 'Smith'
});
objection chains query methods.
- Starts with
query()on the model class. - Feels very close to writing SQL.
// objection: Fetching
const user = await User.query().findOne({
lastName: 'Smith'
});
bookshelf uses instance methods.
- You often create a new model instance before fetching.
- Uses
.fetch()to execute the query.
// bookshelf: Fetching
const user = await new User({ lastName: 'Smith' }).fetch();
🔗 Handling Relationships
Real apps rarely have just one table. Joining users to posts or orders is critical.
sequelize defines associations explicitly.
- Use
hasMany,belongsTo, etc., after defining models. - Eager loading is done via the
includeoption.
// sequelize: Relations
User.hasMany(Post);
const user = await User.findOne({
where: { id: 1 },
include: [Post]
});
typeorm defines relations inside the entity class.
- Decorators like
@OneToManydescribe the link. - Relations are loaded via
relationsoption or joins.
// typeorm: Relations
@OneToMany(() => Post, post => post.user)
posts: Post[];
// Fetching with relations
const user = await userRepository.findOne({
where: { id: 1 },
relations: ['posts']
});
objection uses a static relationMappings object.
- Keeps relation logic separate from instance data.
- Uses
withGraphFetchedto load related data.
// objection: Relations
static get relationMappings() {
return {
posts: {
relation: Model.HasManyRelation,
modelClass: Post,
join: { from: 'users.id', to: 'posts.userId' }
}
};
}
// Fetching
const user = await User.query().findById(1).withGraphFetched('posts');
bookshelf defines relations as methods on the model.
- Return a
this.hasManyorthis.belongsTocall. - Uses
.fetch({ withRelated: [...] })to load.
// bookshelf: Relations
posts() {
return this.hasMany(Post);
}
// Fetching
const user = await new User({ id: 1 }).fetch({
withRelated: ['posts']
});
🛡️ TypeScript Support
For frontend developers moving to full-stack, type safety is non-negotiable.
sequelize has improved significantly in recent versions.
- Requires generic types for model definitions.
- Can be verbose but provides strong safety.
// sequelize: TS usage
interface UserCreationAttrs {
firstName: string;
}
const User = sequelize.define<User, UserCreationAttrs>('User', {...});
typeorm is built with TypeScript in mind.
- Decorators provide metadata automatically.
- Entities are standard TypeScript classes.
// typeorm: TS usage
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number; // Type is inferred
}
objection supports TypeScript via generics.
- You can pass types to the
Modelclass. - Query builder types are robust due to
knex.
// objection: TS usage
class User extends Model {
id!: number;
firstName!: string;
}
bookshelf has weaker TypeScript support.
- Definitions often require manual type casting.
- Community typings exist but are less maintained.
// bookshelf: TS usage
// Often requires 'any' or complex interface extensions
interface User extends bookshelf.Model<User> {
firstName(): string;
}
📅 Maintenance and Future Proofing
Choosing a library is a long-term commitment. You want to know the team behind it is still active.
sequelize is highly active.
- Regular releases and security patches.
- Large community ensures long-term viability.
typeorm is highly active.
- Frequent updates and strong corporate backing.
- Widely used in the NestJS ecosystem.
objection is actively maintained.
- Keeps pace with
knexupdates. - Preferred modern choice for
knexusers.
bookshelf is in maintenance mode.
- Release cycles are slow compared to others.
- Community momentum has shifted toward
objection. - ⚠️ Recommendation: Avoid for new projects. Evaluate
objectioninstead if you needknex.
📊 Summary Table
| Feature | sequelize | typeorm | objection | bookshelf |
|---|---|---|---|---|
| Pattern | Active Record | Active Record / Data Mapper | Active Record on Knex | Active Record on Knex |
| Setup | sequelize.define | Decorators @Entity | Class extends Model | bookshelf.Model.extend |
| Query Style | Static Methods | Repository | Query Builder Chain | Instance Methods |
| TypeScript | Good (Generics) | Excellent (Decorators) | Good (Generics) | Weak |
| Status | ✅ Active | ✅ Active | ✅ Active | ⚠️ Maintenance |
💡 The Big Picture
sequelize is the reliable workhorse 🐴. It has been around for years, handles complex SQL dialects well, and is a safe bet for traditional backends. If you want something that just works with PostgreSQL or MySQL without extra configuration, this is it.
typeorm is the TypeScript native 📘. If your team lives in TypeScript and uses decorators, this feels the most natural. It is also the default choice if you are using NestJS.
objection is the flexible query builder 🛠️. It gives you the power of knex with the convenience of models. Choose this if you find standard ORMs too restrictive and want to write queries that feel closer to SQL.
bookshelf is the legacy option 🕰️. While it still works, the community has largely moved to objection for knex-based projects. Start with objection if you need that specific architecture.
Final Thought: For most new full-stack projects today, typeorm or sequelize will offer the smoothest experience. If you need raw query power, pick objection. Skip bookshelf for new development to avoid future migration headaches.
How to Choose: typeorm vs sequelize vs objection vs bookshelf
- typeorm:
Choose
typeormif you are heavily invested in TypeScript and prefer using decorators to define entities. It supports both SQL and NoSQL (MongoDB) databases, making it flexible for polyglot persistence. It is often the top pick for NestJS applications and modern full-stack frameworks. - sequelize:
Choose
sequelizeif you need a mature, batteries-included ORM with a strong focus on SQL dialects like PostgreSQL, MySQL, and SQLite. It is well-suited for teams that want a standard Active Record pattern with built-in migrations and validation. It is a safe, stable choice for traditional Node.js backends. - objection:
Choose
objectionif you want the flexibility of theknexquery builder with a cleaner model layer. It is ideal for developers who prefer writing SQL-like queries in JavaScript without giving up model relationships. It shines in projects where you need fine-grained control over queries but still want object mapping. - bookshelf:
Choose
bookshelfonly if you are maintaining a legacy system already using it. It is built onknexbut has seen significantly slower development activity compared to modern alternatives. For new projects, the community generally recommendsobjectionfor aknex-based workflow due to better TypeScript support and active maintenance.
Popular Comparisons
README for typeorm
TypeORM is an ORM that can run in Node.js, Browser, Cordova, Ionic, React Native, NativeScript, Expo, and Electron platforms and can be used with TypeScript and JavaScript (ES2021). Its goal is to always support the latest JavaScript features and provide additional features that help you to develop any kind of application that uses databases - from small applications with a few tables to large-scale enterprise applications with multiple databases.
TypeORM supports more databases than any other JS/TS ORM: Google Spanner, Microsoft SqlServer, MySQL/MariaDB, MongoDB, Oracle, Postgres, SAP HANA and SQLite, as well we derived databases and different drivers.
TypeORM supports both Active Record and Data Mapper patterns, unlike all other JavaScript ORMs currently in existence, which means you can write high-quality, loosely coupled, scalable, maintainable applications in the most productive way.
TypeORM is highly influenced by other ORMs, such as Hibernate, Doctrine and Entity Framework.
Features
- Supports both DataMapper and ActiveRecord (your choice).
- Entities and columns.
- Database-specific column types.
- Entity manager.
- Repositories and custom repositories.
- Clean object-relational model.
- Associations (relations).
- Eager and lazy relations.
- Unidirectional, bidirectional, and self-referenced relations.
- Supports multiple inheritance patterns.
- Cascades.
- Indices.
- Transactions.
- Migrations and automatic migrations generation.
- Connection pooling.
- Replication.
- Using multiple database instances.
- Working with multiple database types.
- Cross-database and cross-schema queries.
- Elegant-syntax, flexible and powerful QueryBuilder.
- Left and inner joins.
- Proper pagination for queries using joins.
- Query caching.
- Streaming raw results.
- Logging.
- Listeners and subscribers (hooks).
- Supports closure table pattern.
- Schema declaration in models or separate configuration files.
- Supports MySQL / MariaDB / Postgres / CockroachDB / SQLite / Microsoft SQL Server / Oracle / SAP Hana / sql.js.
- Supports MongoDB NoSQL database.
- Works in Node.js / Browser / Ionic / Cordova / React Native / NativeScript / Expo / Electron platforms.
- TypeScript and JavaScript support.
- ESM and CommonJS support.
- Produced code is performant, flexible, clean, and maintainable.
- Follows all possible best practices.
- CLI.
And more...
With TypeORM, your models look like this:
import { Entity, PrimaryGeneratedColumn, Column } from "typeorm"
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number
@Column()
firstName: string
@Column()
lastName: string
@Column()
age: number
}
And your domain logic looks like this:
const userRepository = MyDataSource.getRepository(User)
const user = new User()
user.firstName = "Timber"
user.lastName = "Saw"
user.age = 25
await userRepository.save(user)
const allUsers = await userRepository.find()
const firstUser = await userRepository.findOneBy({
id: 1,
}) // find by id
const timber = await userRepository.findOneBy({
firstName: "Timber",
lastName: "Saw",
}) // find by firstName and lastName
await userRepository.remove(timber)
Alternatively, if you prefer to use the ActiveRecord implementation, you can use it as well:
import { Entity, PrimaryGeneratedColumn, Column, BaseEntity } from "typeorm"
@Entity()
export class User extends BaseEntity {
@PrimaryGeneratedColumn()
id: number
@Column()
firstName: string
@Column()
lastName: string
@Column()
age: number
}
And your domain logic will look this way:
const user = new User()
user.firstName = "Timber"
user.lastName = "Saw"
user.age = 25
await user.save()
const allUsers = await User.find()
const firstUser = await User.findOneBy({
id: 1,
})
const timber = await User.findOneBy({
firstName: "Timber",
lastName: "Saw",
})
await timber.remove()
Samples
Take a look at the samples in sample for examples of usage.
There are a few repositories that you can clone and start with:
- Example how to use TypeORM with TypeScript
- Example how to use TypeORM with JavaScript
- Example how to use TypeORM with JavaScript and Babel
- Example how to use TypeORM with TypeScript and SystemJS in Browser
- Example how to use TypeORM with TypeScript and React in Browser
- Example how to use Express and TypeORM
- Example how to use Koa and TypeORM
- Example how to use TypeORM with MongoDB
- Example how to use TypeORM in a Cordova app
- Example how to use TypeORM with an Ionic app
- Example how to use TypeORM with React Native
- Example how to use TypeORM with Nativescript-Vue
- Example how to use TypeORM with Nativescript-Angular
- Example how to use TypeORM with Electron using JavaScript
- Example how to use TypeORM with Electron using TypeScript
Extensions
There are several extensions that simplify working with TypeORM and integrating it with other modules:
- TypeORM integration with TypeDI
- TypeORM integration with routing-controllers
- Models generation from the existing database - typeorm-model-generator
- Fixtures loader - typeorm-fixtures-cli
- ER Diagram generator - typeorm-uml
- another ER Diagram generator - erdia
- Create, drop and seed database - typeorm-extension
- Automatically update
data-source.tsafter generating migrations/entities - typeorm-codebase-sync - Easy manipulation of
relationsobjects - typeorm-relations - Automatically generate
relationsbased on a GraphQL query - typeorm-relations-graphql - Generate TypeORM entities from Valibot schemas - piying-orm
Contributing
Learn about contribution here and how to set up your development environment here.
This project exists thanks to all the people who contribute:
Sponsors
Open source is hard and time-consuming. If you want to invest in TypeORM's future, you can become a sponsor and allow our core team to spend more time on TypeORM's improvements and new features.
Champion
Become a champion sponsor and get premium technical support from our core contributors. Become a champion
Supporter
Support TypeORM's development with a monthly contribution. Become a supporter
Community
Join our community of supporters and help sustain TypeORM. Become a community supporter
Sponsor
Make a one-time or recurring contribution of your choice. Become a sponsor
