I have been using node-orm2 recently. These are my findings:

  1. Promises are the best way to handle asynchronous results now, especially with the advent of async/await. Yet async/await won’t help you with node-orm2 because it uses callbacks everywhere. Sure you can use a library like async to avoid callback hell but promises are much better (even when discounting async/await) because they are composable. This is why they are part of every new HTML5 proposal involving asynchronous results (e.g. the fetch API). Worse: node-orm provide its own incompatible class called Promise which it uses to overrides the built-in implementation and it isn’t anywhere near as useful or performant as native promises.
  2. The library does classes all wrong. Instead of using ES6 classes or prototype it assigns a new copy of each method in the constructor one by one. This is very bad for memory usage, performance and extensibility.
  3. As a consequence of the previous point, you cannot extend any classes provided or created by orm2. You must use the orm2 API to create custom methods on your API, where again they won’t be added to the prototype of the model but as instance members.
  4. Although the library is not completely consistent with its aversion to prototype, it does use the JavaScript object model correctly in the driver modules but nowhere else.
  5. It’s slow and the API is non-uniform.
  6. The documentation is incomplete, some things are only documented on github, some on the wiki and other things, like the method clear, are undocumented.
  7. It is not an active project, there were only 24 commits last year and some PR have been open for over 2 years without response.
  8. It bundles all supported database drivers and other utilities you may or may not need like a middleware for express.
  9. After closing one database connection is it impossible to create a new connection. This forces users of orm2 to come up with a convoluted way of sharing a single database connection across unit tests.
  10. The only type supported for rational numbers when using the mysql or postgresql driver is float rather than double despite the fact that mongo and most modern dynamic programming languages only support double precision floating-point numbers.
  11. Auto-incrementing primary keys have to be of int type (not bigint as in probably every competent database model you’ve ever seen), this is hardcoded.
  12. It is much harder to promisify the API due to its aversion to the use of prototype.

Lately I’ve been questioning if ORMs are a good idea. I’ve also been looking at sequelize, a project that has recently become much more active than orm2. It provide a better promise based API and better documentation. I’ve also used mongoose in the past which is a reasonable choice when you are using mongo (but before choosing mongo always make sure it fits your data).