Nine database families are the reason to choose it
TypeORM supports PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, SAP HANA, Google Spanner, MongoDB, and related drivers. That breadth is the buying argument. A company with several database engines can keep one entity and repository model instead of teaching each application a different ORM. The README also covers replication, multiple data sources, cross-schema queries, database-specific column types, and migration generation. A small service tied to one PostgreSQL cluster gets less value from carrying all that surface.
The same package reaches Node.js, Electron, Expo, React Native, Cordova, Ionic, NativeScript, and browser use. JavaScript and TypeScript are both supported, as are ESM and CommonJS. Those combinations give an established product room to move, but each extra driver and runtime creates another place where bundling, connection behavior, or a database dialect can differ. Before adoption, build one representative path on the exact runtime and database you will deploy.
Two persistence styles share one package
The README shows two ways to save the same User. A repository obtained from a DataSource supports Data Mapper code, while extending BaseEntity puts methods such as save() on the model itself. Both styles include relations, cascades, transactions, listeners, query building, and schema metadata. That choice is useful when migrating an old application or accommodating separate teams. Within one codebase, however, it can also create two house styles for the same work. Pick one default and document exceptions.
A DataSource owns connection settings and initializes a connection or pool. A normal server creates it during startup, shares it across handlers, and closes it when the process ends. Credentials and driver packages depend on the chosen database; SQLite or sql.js can avoid an external server, while PostgreSQL, MySQL, Oracle, and SQL Server require their own services. The compact entity sample is genuine, but it sits after those operating decisions.
What happened when we ran it
Our sandbox cloned commit 17e858d into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Pnpm installed 962 packages in 25 seconds and occupied 550 MB. The checkout itself contained 3,806 files, about 309,081 lines of source, and used 12.8 MB. The harness found no build script or target, so it skipped build. That result confirms dependency installation only.
The test command failed with exit code 1 after 38 seconds. Its visible tail runs through Mocha's formattedImport, requireOrImport, and loadFilesAsync, followed by pnpm reporting that typeorm@1.1.1 test failed. The original exception is absent from the supplied tail. We cannot say whether a module, configuration choice, database service, or another condition caused it. The defensible finding is that commit 17e858d did not give us a green default test run.
Our scan found 11 CI workflow files, a compose file, no Dockerfile, and no root tests directory. The repository is a pnpm workspace whose main package lives under packages/typeorm. Current contributor instructions explain that the root test task delegates there, first compiles, then runs the faster test command. The 550 MB install is contributor cost rather than the size every application ships, yet it still affects local setup, CI caches, and dependency review.
Five database servers sit behind the full suite
TypeORM's developer guide asks contributors to copy the sample ORM configuration and choose which database definitions to keep. MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server are named prerequisites for their respective test paths. Docker Compose can start several services, including a documented PostgreSQL 17 target, while Oracle remains a separate requirement. One command can invoke the suite, but a meaningful multi-driver run depends on services and configuration outside pnpm.
That distinction matters when reading our 38-second failure. The log tail does not identify a missing service, and the sandbox result must not be stretched into that claim. It does show that installation success did not carry through to tests under a clean Node 22 environment. A team evaluating a driver should run its own database-specific cases, one migration cycle, and the transaction paths it expects to use.
Migration generation still requires human review
Open issue 12933 documents a concrete TypeORM 1.1.1 edge case with better-sqlite3. If migration A is generated but left unapplied, then the entity changes again, migration B can repeat creation of the same table. Both generation commands report success, but running the sequence fails because the table already exists. The issue asks for a warning or refusal when pending migrations exist. Until that changes, generated files belong in code review and should be tested from an empty database.
Recent work also shows maintainers addressing low-level behavior rather than leaving the project still. Release 1.1.1 shipped on September 1, 2026, with fixes for relation values, junction rows, query-runner cleanup, database-specific events, and query grouping. GitHub recorded a push on October 7 and 36,664 stars, with 687 open issues and pull requests combined. That queue is large, yet the recent push and release show active maintenance across a wide compatibility burden.
One SQL engine may not justify this surface
Prisma makes sense when a central schema and generated client are the preferred contract. Drizzle keeps TypeScript queries closer to SQL, while MikroORM concentrates on Data Mapper mechanics. TypeORM earns its place when its particular mix matters: many databases, several runtimes, mature entity mapping, and a choice of persistence style. Existing applications also gain more from continuity than a greenfield comparison suggests.
Our run leaves a precise caution. The 25-second install worked, but 962 packages, 550 MB, and a failed test command are meaningful costs for anyone changing TypeORM itself. Pair that with database-specific test services and migration review. If your project needs the driver breadth, those costs can be reasonable. If it needs one ordinary SQL path, choose the smaller mental model you can explain during an incident.