bookshelf, mongoose, sequelize, and waterline are libraries that help Node.js applications interact with databases by organizing data into models. mongoose is designed for MongoDB and uses a document-based approach, while sequelize, bookshelf, and waterline support relational SQL databases like PostgreSQL and MySQL. These tools handle connections, define data shapes, and simplify queries so developers do not need to write raw SQL or database commands for every action. Choosing the right one depends on your database type, project size, and long-term maintenance needs.
When building Node.js backends β whether for API servers, serverless functions, or full-stack frameworks β you need a reliable way to talk to your database. bookshelf, mongoose, sequelize, and waterline all solve this problem, but they target different databases and work in different ways. Let's compare how they handle common engineering tasks.
The first decision is your database type. This choice often dictates which library you can use.
mongoose works only with MongoDB.
// mongoose: MongoDB only
const mongoose = require('mongoose');
// Connects to MongoDB instance
mongoose.connect('mongodb://localhost:27017/myapp');
sequelize works with SQL databases.
// sequelize: SQL databases
const { Sequelize } = require('sequelize');
// Connects to SQL instance
const sequelize = new Sequelize('postgres://user:pass@localhost:5432/db');
bookshelf works with SQL databases via Knex.js.
// bookshelf: SQL databases via Knex
const knex = require('knex')({ client: 'pg' });
const bookshelf = require('bookshelf')(knex);
// Uses Knex connection for SQL
waterline works with both SQL and NoSQL via adapters.
// waterline: Adapter-based
const Waterline = require('waterline');
const waterline = new Waterline();
// Adapters determine DB type (mongo, postgres, etc.)
Each library has a different way to define what your data looks like.
mongoose uses Schemas to define document structure.
// mongoose: Schema definition
const userSchema = new mongoose.Schema({
name: String,
email: { type: String, unique: true }
});
const User = mongoose.model('User', userSchema);
sequelize uses Model Definitions with data types.
// sequelize: Model definition
const User = sequelize.define('User', {
name: { type: Sequelize.STRING },
email: { type: Sequelize.STRING, unique: true }
});
bookshelf extends a Base Model with table names.
// bookshelf: Model extension
const User = bookshelf.Model.extend({
tableName: 'users',
// Validation handled externally or via plugins
});
waterline uses Collection Definitions.
// waterline: Collection definition
const User = waterline.Collection.extend({
tableName: 'users',
attributes: {
name: { type: 'string' },
email: { type: 'string', unique: true }
}
});
How you retrieve data varies significantly between these tools.
mongoose uses Chainable Queries on models.
find, findOne, findById are standard.// mongoose: Finding documents
const users = await User.find({ role: 'admin' });
const user = await User.findOne({ email: 'test@example.com' });
sequelize uses Finder Methods with options objects.
findAll, findOne, findByPk are common.// sequelize: Finding rows
const users = await User.findAll({ where: { role: 'admin' } });
const user = await User.findOne({ where: { email: 'test@example.com' } });
bookshelf uses Knex-style Querying on models.
where, fetch, fetchAll methods.// bookshelf: Fetching models
const users = await User.where({ role: 'admin' }).fetchAll();
const user = await User.where({ email: 'test@example.com' }).fetch();
waterline uses Criteria Objects for queries.
find, findOne accept simple objects.// waterline: Finding records
const users = await User.find({ role: 'admin' });
const user = await User.findOne({ email: 'test@example.com' });
For professional developers, long-term support is critical. You do not want to build on a library that stops receiving updates.
mongoose is highly active.
sequelize is highly active.
bookshelf has low activity.
waterline has low activity standalone.
| Feature | mongoose | sequelize | bookshelf | waterline |
|---|---|---|---|---|
| Database | π MongoDB only | ποΈ SQL (Postgres, MySQL) | ποΈ SQL (via Knex) | π Both (via adapters) |
| Style | π Document ODM | ποΈ Relational ORM | ποΈ Relational ORM | π Datastore Agnostic |
| Activity | π’ High | π’ High | π‘ Low | π‘ Low |
| Best For | π New Mongo Apps | π’ Enterprise SQL | π°οΈ Legacy Knex Apps | β΅ Sails.js Apps |
mongoose and sequelize are the industry standards for new projects. Choose mongoose for MongoDB and sequelize for SQL databases. They have the best documentation, community support, and active maintenance.
bookshelf and waterline are older tools with specific use cases. bookshelf fits if you love Knex and need a light model layer. waterline fits if you are already using Sails.js. For most other scenarios, the active maintenance of mongoose and sequelize makes them the safer choice for long-term stability.
Final Thought: Your database choice should drive your library choice. Pick your database first based on data needs, then pick the library that supports it best with active community backing.
Choose bookshelf if you are already using Knex.js and want a thin model layer on top of it for SQL databases. It is suitable for legacy projects or teams that prefer explicit control over SQL queries without heavy abstraction. However, be aware that development activity has slowed, so it may not be the best fit for new greenfield projects requiring long-term support.
Choose mongoose if your application uses MongoDB and you need a robust schema system with built-in validation. It is the standard choice for Node.js and MongoDB, offering strong community support and extensive plugins. This is ideal for content-heavy apps, real-time data, or when your data structure changes frequently.
Choose sequelize if you are working with relational databases like PostgreSQL, MySQL, or SQLite and want a feature-rich ORM. It supports migrations, associations, and transactions out of the box, making it great for complex business logic. It is widely maintained and a safe bet for enterprise-grade SQL applications.
Choose waterline primarily if you are building an application with the Sails.js framework, as it is tightly integrated into that ecosystem. It supports both SQL and NoSQL databases through adapters, offering flexibility if you need to switch database types later. For standalone Node.js projects outside of Sails, other options may offer better documentation and community support.
Bookshelf is a JavaScript ORM for Node.js, built on the Knex SQL query builder. It features both Promise-based and traditional callback interfaces, transaction support, eager/nested-eager relation loading, polymorphic associations, and support for one-to-one, one-to-many, and many-to-many relations.
It is designed to work with PostgreSQL, MySQL, and SQLite3.
Website and documentation. The project is hosted on GitHub, and has a comprehensive test suite.
Bookshelf aims to provide a simple library for common tasks when querying databases in JavaScript, and forming relations between these objects, taking a lot of ideas from the Data Mapper Pattern.
With a concise, literate codebase, Bookshelf is simple to read, understand, and extend. It doesn't force you to use any specific validation scheme, and provides flexible, efficient relation/nested-relation loading and first-class transaction support.
It's a lean object-relational mapper, allowing you to drop down to the raw Knex interface whenever you need a custom query that doesn't quite fit with the stock conventions.
You'll need to install a copy of Knex, and either mysql, pg, or sqlite3 from npm.
$ npm install knex
$ npm install bookshelf
# Then add one of the following:
$ npm install pg
$ npm install mysql
$ npm install sqlite3
The Bookshelf library is initialized by passing an initialized Knex client instance. The Knex documentation provides a number of examples for different databases.
// Setting up the database connection
const knex = require('knex')({
client: 'mysql',
connection: {
host : '127.0.0.1',
user : 'your_database_user',
password : 'your_database_password',
database : 'myapp_test',
charset : 'utf8'
}
})
const bookshelf = require('bookshelf')(knex)
// Defining models
const User = bookshelf.model('User', {
tableName: 'users'
})
This initialization should likely only ever happen once in your application. As it creates a connection pool for the current database, you should use the bookshelf instance returned throughout your library. You'll need to store this instance created by the initialize somewhere in the application so you can reference it. A common pattern to follow is to initialize the client in a module so you can easily reference it later:
// In a file named, e.g. bookshelf.js
const knex = require('knex')(dbConfig)
module.exports = require('bookshelf')(knex)
// elsewhere, to use the bookshelf client:
const bookshelf = require('./bookshelf')
const Post = bookshelf.model('Post', {
// ...
})
Here is an example to get you started:
const knex = require('knex')({
client: 'mysql',
connection: process.env.MYSQL_DATABASE_CONNECTION
})
const bookshelf = require('bookshelf')(knex)
const User = bookshelf.model('User', {
tableName: 'users',
posts() {
return this.hasMany(Posts)
}
})
const Post = bookshelf.model('Post', {
tableName: 'posts',
tags() {
return this.belongsToMany(Tag)
}
})
const Tag = bookshelf.model('Tag', {
tableName: 'tags'
})
new User({id: 1}).fetch({withRelated: ['posts.tags']}).then((user) => {
console.log(user.related('posts').toJSON())
}).catch((error) => {
console.error(error)
})
.set() on a model.Model, adding timestamps, attribute validation and some native CRUD methods.Have questions about the library? Come join us in the #bookshelf freenode IRC channel for support on knex.js and bookshelf.js, or post an issue on Stack Overflow.
If you want to contribute to Bookshelf you'll usually want to report an issue or submit a pull-request. For this purpose the online repository is available on GitHub.
For further help setting up your local development environment or learning how you can contribute to Bookshelf you should read the Contributing document available on GitHub.
Yes, you can call .asCallback(function(err, resp) { on any database operation method and use the standard (err, result) style callback interface if you prefer.
Make sure to check that the type is correct for the initial parameters passed to the initial model being fetched. For example new Model({id: '1'}).load([relations...]) will not return the same as new Model({id: 1}).load([relations...]) - notice that the id is a string in one case and a number in the other. This can be a common mistake if retrieving the id from a url parameter.
This is only an issue if you're eager loading data with load without first fetching the original model. new Model({id: '1'}).fetch({withRelated: [relations...]}) should work just fine.
The issue here is that Knex, the database abstraction layer used by Bookshelf, uses connection pooling and thus keeps the database connection open. If you want your process to exit after your script has finished, you will have to call .destroy(cb) on the knex property of your Bookshelf instance or on the Knex instance passed during initialization. More information about connection pooling can be found over at the Knex docs.
If you pass debug: true in the options object to your knex initialize call, you can see all of the query calls being made. You can also pass that same option to all methods that access the database, like model.fetch() or model.destroy(). Examples:
// Turning on debug mode for all queries
const knex = require('knex')({
debug: true,
client: 'mysql',
connection: process.env.MYSQL_DATABASE_CONNECTION
})
const bookshelf = require('bookshelf')(knex)
// Debugging a single query
new User({id: 1}).fetch({debug: true, withRelated: ['posts.tags']}).then(user => {
// ...
})
Sometimes you need to dive a bit further into the various calls and see what all is going on behind the scenes. You can use node-inspector, which allows you to debug code with debugger statements like you would in the browser.
Bookshelf uses its own copy of the bluebird Promise library. You can read up here for more on debugging Promises.
Adding the following block at the start of your application code will catch any errors not otherwise caught in the normal Promise chain handlers, which is very helpful in debugging:
process.stderr.on('data', (data) => {
console.log(data)
})
See the CONTRIBUTING document on GitHub.
While it primarily targets Node.js, all dependencies are browser compatible, and it could be adapted to work with other javascript environments supporting a sqlite3 database, by providing a custom Knex adapter. No such adapter exists though.
We found the following projects using Bookshelf, but there can be more: