Alternatives to TypeORM logo

Alternatives to TypeORM

Sequelize, Mongoose, LoopBack, Prisma, and MikroORM are the most popular alternatives and competitors to TypeORM.
599
808
+ 1
81

What is TypeORM and what are its top alternatives?

TypeORM is an Object-Relational Mapping (ORM) framework for TypeScript and JavaScript that allows developers to work with databases using classes and objects. Its key features include support for various database systems, entity relationships, and migrations. However, some limitations of TypeORM include a steep learning curve and occasional bugs or performance issues.

  1. Sequelize: Sequelize is a promise-based Node.js ORM for PostgreSQL, MySQL, MariaDB, SQLite, and Microsoft SQL Server, offering support for transactions, relations, and migrations. Pros include a large community and extensive documentation, but some users may find it complex to set up.
  2. Prisma: Prisma is a modern database toolkit that simplifies database access with type safety, auto-generated queries, and migrations. Its pros include type safety and powerful query generation, while it may be limited in terms of database support compared to TypeORM.
  3. Knex.js: Knex.js is a SQL query builder for JavaScript with support for multiple database systems, migrations, and transactions. Its pros include ease of use and flexibility, but it may not offer the same level of abstraction as TypeORM.
  4. Bookshelf.js: Bookshelf.js is an ORM for Node.js built on top of Knex.js, providing a simple and flexible way to interact with databases. Pros include simplicity and ease of use, but it may lack some advanced features found in TypeORM.
  5. Typegoose: Typegoose is a MongoDB modeling framework for TypeScript that combines the advantages of Mongoose with TypeScript's type system. Pros include type safety and ease of use with MongoDB, but it is limited to working with MongoDB only.
  6. Waterline: Waterline is a data storage layer that provides a uniform API for accessing various databases, offering flexibility and compatibility with different databases. However, it may not provide the same level of TypeScript support as TypeORM.
  7. Objection.js: Objection.js is a SQL-friendly ORM for Node.js built on top of Knex.js, providing a query builder and relation mapping. Pros include an intuitive API and performance optimizations, but it may lack some advanced features offered by TypeORM.
  8. MikroORM: MikroORM is a TypeScript ORM inspired by TypeORM but focuses on simplicity and developer productivity with features such as entity validation and schema generation. Its pros include an active community and performance optimizations, while it may lack some advanced features present in TypeORM.
  9. Sails.js: Sails.js is a full-featured MVC framework for Node.js that includes Waterline as its ORM for database interactions, offering a scaffolding feature and blueprint API. Pros include rapid development and a plugin ecosystem, but it may not provide as much control as TypeORM.
  10. Django ORM: Django ORM is a powerful ORM system for Python web framework Django, providing an abstraction layer for database interactions with support for relations, transactions, and migrations. Its pros include ease of use and a rich feature set, but it is limited to Python development compared to TypeORM.

Top Alternatives to TypeORM

  • Sequelize
    Sequelize

    Sequelize is a promise-based ORM for Node.js and io.js. It supports the dialects PostgreSQL, MySQL, MariaDB, SQLite and MSSQL and features solid transaction support, relations, read replication and more. ...

  • Mongoose
    Mongoose

    Let's face it, writing MongoDB validation, casting and business logic boilerplate is a drag. That's why we wrote Mongoose. Mongoose provides a straight-forward, schema-based solution to modeling your application data and includes built-in type casting, validation, query building, business logic hooks and more, out of the box. ...

  • LoopBack
    LoopBack

    A highly-extensible, open-source Node.js framework that enables you to create dynamic end-to-end REST APIs with little or no coding. Connect to multiple data sources, write business logic in Node.js, glue on top of your existing services and data, connect using JS, iOS & Android SDKs. ...

  • Prisma
    Prisma

    Prisma is an open-source database toolkit. It replaces traditional ORMs and makes database access easy with an auto-generated query builder for TypeScript & Node.js. ...

  • MikroORM
    MikroORM

    TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, PostgreSQL and SQLite databases. ...

  • Entity Framework
    Entity Framework

    It is an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. It eliminates the need for most of the data-access code that developers usually need to write. ...

  • GraphQL
    GraphQL

    GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012. ...

  • JavaScript
    JavaScript

    JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...

TypeORM alternatives & related posts

Sequelize logo

Sequelize

878
1.4K
143
Easy-to-use multi SQL dialect ORM for Node.js
878
1.4K
+ 1
143
PROS OF SEQUELIZE
  • 42
    Good ORM for node.js
  • 31
    Easy setup
  • 21
    Support MySQL & MariaDB, PostgreSQL, MSSQL, Sqlite
  • 14
    Open source
  • 13
    Free
  • 12
    Promise Based
  • 4
    Recommend for mongoose users
  • 3
    Typescript
  • 3
    Atrocious documentation, buggy, issues closed by bots
CONS OF SEQUELIZE
  • 30
    Docs are awful
  • 10
    Relations can be confusing

related Sequelize posts

Dieudonné ALLOGNON
Junior Fullstack Developer · | 5 upvotes · 333.5K views

Hey! I am actually in internship and have an app to create for my structure. It will be an intern app which will allow crud dashboard actions with some data provided by the use of an API of one of the structure partner and make a correspondence to data contained in a private database. Since it's an intern app, I thought about Electron for a desktop app because I did a lot of web with Laravel and the structure goes more for the desktop app. But it will be my first occasion working with this tech.

Is Electron a good choice? Wich ORM should be more complete and adapted to this between Sequelize and TypeORM? (Database will be MySQL) Some charts will be displayed in the app. Is there a library (preferably without jQuery) that suits this stack?

Thank you !

See more
Max Musing
Founder & CEO at BaseDash · | 5 upvotes · 98.7K views

Node.js is a great option for real-time applications, especially in conjunction with Socket.IO.

In terms of databases, I'd go with PostgreSQL. MongoDB has its benefits (schema-less, sharding, map-reduce), but for most CRUD-based apps, it makes sense to store the bulk of your data in a relational database (of which PostgreSQL is the best IMO). You can throw in MongoDB if you have a specific need for it. There's certainly no need to use both MySQL and PostgreSQL.

As for GraphQL, it can be nice to work with since you don't need to predefine specific data endpoints on your backend, instead shifting the power to your frontend in requesting the data it needs. It's also useful for public APIs, when you don't know what data users want (see Github's API). It can be useful at the early stage when you're prototyping and want to be able to fetch data quickly, but certainly isn't necessary.

At BaseDash we use Node.js, ExpressJS, Socket.IO, PostgreSQL, and Sequelize to fit our use case of database management and real-time operations.

See more
Mongoose logo

Mongoose

2.1K
1.4K
56
MongoDB object modeling designed to work in an asynchronous environment
2.1K
1.4K
+ 1
56
PROS OF MONGOOSE
  • 17
    Several bad ideas mixed together
  • 17
    Well documented
  • 10
    JSON
  • 8
    Actually terrible documentation
  • 2
    Recommended and used by Valve. See steamworks docs
  • 1
    Can be used with passportjs for oauth
  • 1
    Yeah
CONS OF MONGOOSE
  • 3
    Model middleware/hooks are not user friendly

related Mongoose posts

Repost

Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

See more

REST API for SaaS application

I'm currently developing an Azure Functions REST API with TypeScript, tsoa, Mongoose, and Typegoose that contains simple CRUD activities. It does the job and has type-safety as well as the ability to generate OpenAPI specs for me.

However, as the app scales up, there are more duplicated codes (for similar operations - like CRUD in each different model). It's also becoming more complex because I need to implement a multi-tenancy SaaS for both the API and the database.

So I chose to implement a repository pattern, and I have a "feeling" that .NET and C# will make development easier because, unlike TypeScript, it includes native support for Dependency Injection and great things like LINQ.

It wouldn't take much effort to migrate because I can easily translate interfaces and basic CRUD operations to C#. So, I'm looking for advice on whether it's worth converting from TypeScript to.NET.

See more
LoopBack logo

LoopBack

287
556
33
Build modern API applications that require complex integrations
287
556
+ 1
33
PROS OF LOOPBACK
  • 11
    Need a nodejs ReST-API, DB, AAA, Swagger? Then loopback
  • 9
    Easy Database Migration
  • 6
    Code generator
  • 4
    The future of API's
  • 2
    GraphQL
  • 1
    Typescript
CONS OF LOOPBACK
  • 7
    Community is slow
  • 1
    Backward compatibility

related LoopBack posts

Priit Kaasik
CTO at Katana Cloud Inventory · | 8 upvotes · 472K views

We undertook the task of building a manufacturing ERP for small branded manufacturers. We needed to build a lot, fast with a small team, and have clear focus on product delivery. We chose JavaScript / Node.js ( React + LoopBack full stack) , Heroku and Heroku Postgres (also Heroku Redis ) . This decision has guided us to picking other key technologies. It has granted us high pace of product delivery and service availability while operating with a small team.

See more

We have an existing (Apis only) Rails backend, that by default follows the MVC pattern, (at peaks of 700 requests a second). I am tasked with making the same (read-heavy) application in any JavaScript framework. I was advised to follow the MVC structure. So I am considering these 3 ( Sails.js, LoopBack, NestJS). I get that sails is closest to rails, but that's not particularly a priority.

See more
Prisma logo

Prisma

1.1K
948
54
Modern Database Access for TypeScript & Node.js
1.1K
948
+ 1
54
PROS OF PRISMA
  • 12
    Type-safe database access
  • 10
    Open Source
  • 8
    Auto-generated query builder
  • 6
    Supports multible database systems
  • 6
    Increases confidence during development
  • 4
    Built specifically for Postgres and TypeScript
  • 4
    Productive application development
  • 2
    Supports multible RDBMSs
  • 2
    Robust migrations system
CONS OF PRISMA
  • 2
    Doesn't support downward/back migrations
  • 1
    Doesn't support JSONB
  • 1
    Do not support JSONB
  • 1
    Mutation of JSON is really confusing
  • 1
    Do not support JSONB

related Prisma posts

Divine Bawa
at PayHub Ghana Limited · | 16 upvotes · 484.6K views

I just finished a web app meant for a business that offers training programs for certain professional courses. I chose this stack to test out my skills in graphql and react. I used Node.js , GraphQL , MySQL for the #Backend utilizing Prisma as a database interface for MySQL to provide CRUD APIs and graphql-yoga as a server. For the #frontend I chose React, styled-components for styling, Next.js for routing and SSR and Apollo for data management. I really liked the outcome and I will definitely use this stack in future projects.

See more
Collins Ogbuzuru
Front-end dev at Evolve credit · | 15 upvotes · 27.1K views
Shared insights
on
GraphQLGraphQLPrismaPrismaAWS LambdaAWS Lambda

We are starting to build one shirt data logic, structure and as an online clothing store we believe good ux and ui is a goal to drive a lot of click through. The problem is, how do we fetch data and how do we abstract the gap between the Front-end devs and backend-devs as we are just two in the technical unit. We decided to go for GraphQL as our application-layer tool and Prisma for our database-layer abstracter.

Reasons :

GraphQL :

  1. GraphQL makes fetching of data less painful and organised.

  2. GraphQL gives you 100% assurance on data you getting back as opposed to the Rest design .

  3. GraphQL comes with a bunch of real-time functionality in form of. subscriptions and finally because we are using React (GraphQL is not React demanding, it's doesn't require a specific framework, language or tool, but it definitely makes react apps fly )

Prisma :

  1. Writing revolvers can be fun, but imagine writing revolvers nested deep down, curry braces flying around. This is sure a welcome note to bugs and as a small team we need to focus more on what that matters more. Prisma generates this necessary CRUD resolves, mutations and subscription out of the box.

  2. We don't really have much budget at the moment so we are going to run our logic in a scalable cheap and cost effective cloud environment. Oh! It's AWS Lambda and deploying our schema to Lambda is our best bet to minimize cost and same time scale.

We are still at development stage and I believe, working on this start up will increase my dev knowledge. Off for Lunch :)

See more
MikroORM logo

MikroORM

18
67
24
TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns
18
67
+ 1
24
PROS OF MIKROORM
  • 5
    Typescript
  • 4
    Supports both SQL and NoSQL
  • 3
    Powered by Unit of Work and Identity Map
  • 3
    Allows multiple ways to define entities
  • 3
    DRY Entities
  • 2
    Implicit Transactions
  • 2
    SQL layer built on top of Knex
  • 2
    EntityGenerator to reverse engineer existing database
CONS OF MIKROORM
    Be the first to leave a con

    related MikroORM posts

    Entity Framework logo

    Entity Framework

    654
    234
    19
    An object-relational mapper that enables .NET developers to work with relational data
    654
    234
    + 1
    19
    PROS OF ENTITY FRAMEWORK
    • 6
      LINQ
    • 3
      Object Oriented
    • 3
      Strongly Object-Oriented
    • 2
      Multiple approach (Model/Database/Code) first
    • 2
      Code first approach
    • 1
      Auto generated code
    • 1
      Model first approach
    • 1
      Strongly typed entities
    • 0
      Database first
    CONS OF ENTITY FRAMEWORK
      Be the first to leave a con

      related Entity Framework posts

      Hi Friends, I am planning to create a web and mobile app for eCommerce purposes, which is very similar to Swiggy.com/Zomato. Started this app and created API using .NET Core, Entity Framework, and Microsoft SQL Server as DB. Consuming this API in Flutter for mobile and web UI. Just want some help and suggestions about this selection. Worrying about the application's scalability and performance, please suggest me a good architecture to create this application, which may be used by more people over a period of time.

      See more
      GraphQL logo

      GraphQL

      33.6K
      27.6K
      310
      A data query language and runtime
      33.6K
      27.6K
      + 1
      310
      PROS OF GRAPHQL
      • 75
        Schemas defined by the requests made by the user
      • 63
        Will replace RESTful interfaces
      • 62
        The future of API's
      • 49
        The future of databases
      • 13
        Self-documenting
      • 12
        Get many resources in a single request
      • 6
        Query Language
      • 6
        Ask for what you need, get exactly that
      • 3
        Fetch different resources in one request
      • 3
        Type system
      • 3
        Evolve your API without versions
      • 2
        Ease of client creation
      • 2
        GraphiQL
      • 2
        Easy setup
      • 1
        "Open" document
      • 1
        Fast prototyping
      • 1
        Supports subscription
      • 1
        Standard
      • 1
        Good for apps that query at build time. (SSR/Gatsby)
      • 1
        1. Describe your data
      • 1
        Better versioning
      • 1
        Backed by Facebook
      • 1
        Easy to learn
      CONS OF GRAPHQL
      • 4
        Hard to migrate from GraphQL to another technology
      • 4
        More code to type.
      • 2
        Takes longer to build compared to schemaless.
      • 1
        No support for caching
      • 1
        All the pros sound like NFT pitches
      • 1
        No support for streaming
      • 1
        Works just like any other API at runtime
      • 1
        N+1 fetch problem
      • 1
        No built in security

      related GraphQL posts

      Shared insights
      on
      Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

      I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

      For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

      1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

      2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

      3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

      See more
      Nick Rockwell
      SVP, Engineering at Fastly · | 46 upvotes · 3.8M views

      When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

      So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

      React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

      Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

      See more
      JavaScript logo

      JavaScript

      358.4K
      272.4K
      8.1K
      Lightweight, interpreted, object-oriented language with first-class functions
      358.4K
      272.4K
      + 1
      8.1K
      PROS OF JAVASCRIPT
      • 1.7K
        Can be used on frontend/backend
      • 1.5K
        It's everywhere
      • 1.2K
        Lots of great frameworks
      • 898
        Fast
      • 745
        Light weight
      • 425
        Flexible
      • 392
        You can't get a device today that doesn't run js
      • 286
        Non-blocking i/o
      • 237
        Ubiquitousness
      • 191
        Expressive
      • 55
        Extended functionality to web pages
      • 49
        Relatively easy language
      • 46
        Executed on the client side
      • 30
        Relatively fast to the end user
      • 25
        Pure Javascript
      • 21
        Functional programming
      • 15
        Async
      • 13
        Full-stack
      • 12
        Setup is easy
      • 12
        Future Language of The Web
      • 12
        Its everywhere
      • 11
        Because I love functions
      • 11
        JavaScript is the New PHP
      • 10
        Like it or not, JS is part of the web standard
      • 9
        Expansive community
      • 9
        Everyone use it
      • 9
        Can be used in backend, frontend and DB
      • 9
        Easy
      • 8
        Most Popular Language in the World
      • 8
        Powerful
      • 8
        Can be used both as frontend and backend as well
      • 8
        For the good parts
      • 8
        No need to use PHP
      • 8
        Easy to hire developers
      • 7
        Agile, packages simple to use
      • 7
        Love-hate relationship
      • 7
        Photoshop has 3 JS runtimes built in
      • 7
        Evolution of C
      • 7
        It's fun
      • 7
        Hard not to use
      • 7
        Versitile
      • 7
        Its fun and fast
      • 7
        Nice
      • 7
        Popularized Class-Less Architecture & Lambdas
      • 7
        Supports lambdas and closures
      • 6
        It let's me use Babel & Typescript
      • 6
        Can be used on frontend/backend/Mobile/create PRO Ui
      • 6
        1.6K Can be used on frontend/backend
      • 6
        Client side JS uses the visitors CPU to save Server Res
      • 6
        Easy to make something
      • 5
        Clojurescript
      • 5
        Promise relationship
      • 5
        Stockholm Syndrome
      • 5
        Function expressions are useful for callbacks
      • 5
        Scope manipulation
      • 5
        Everywhere
      • 5
        Client processing
      • 5
        What to add
      • 4
        Because it is so simple and lightweight
      • 4
        Only Programming language on browser
      • 1
        Test
      • 1
        Hard to learn
      • 1
        Test2
      • 1
        Not the best
      • 1
        Easy to understand
      • 1
        Subskill #4
      • 1
        Easy to learn
      • 0
        Hard 彤
      CONS OF JAVASCRIPT
      • 22
        A constant moving target, too much churn
      • 20
        Horribly inconsistent
      • 15
        Javascript is the New PHP
      • 9
        No ability to monitor memory utilitization
      • 8
        Shows Zero output in case of ANY error
      • 7
        Thinks strange results are better than errors
      • 6
        Can be ugly
      • 3
        No GitHub
      • 2
        Slow
      • 0
        HORRIBLE DOCUMENTS, faulty code, repo has bugs

      related JavaScript posts

      Zach Holman

      Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

      But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

      But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

      Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

      See more
      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 12.4M views

      How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

      Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

      Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

      https://eng.uber.com/distributed-tracing/

      (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

      Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

      See more