Sequelize 6.37.8 is stable, while version 7 remains alpha
Sequelize v6.37.8 is the current stable release, and it is the safer default for a production application today. The README sends newcomers to separate version 6 and version 7 guides, with version 7 labeled alpha. Main has already become a Yarn workspace whose core package reports 7.0.0-alpha.48, separate dialect packages, and a new CLI package. That split matters because examples, installation commands, Node requirements, and migration tooling can differ. Pick a major version first, then stay inside its documentation.
Our commit 704b36e checkout had 944 files, about 177,422 lines of source, and occupied 9.7 MB before dependencies. Installation expanded it to 1,425 packages and 721 MB. That is contributor overhead, not the footprint of every application that installs one published Sequelize package and a connector. Still, it shows what working on the whole database matrix costs. The monorepo contains core, CLI, validator, utility, and dialect packages, with Lerna and Nx coordinating their builds.
Version 6 covers nine database families through one model API
The README lists Postgres, MySQL, MariaDB, SQLite, DB2, Microsoft SQL Server, Snowflake, Oracle Database, and Db2 for IBM i. Across them, Sequelize handles models, associations, eager and lazy loading, transactions, and read replication. The benefit is a common JavaScript vocabulary for routine database work. The limit is visible in the documentation structure: dialect-specific behavior still gets its own section, and raw queries remain a supported escape route. An ORM can organize SQL work without making different databases identical.
Connector separation in version 7 makes that boundary more explicit. The main core package has a defined Node engine range, while packages such as @sequelize/postgres and @sequelize/sqlite3 carry their drivers. Source contributors can run SQLite locally, but the contribution guide calls Docker practically mandatory for testing other engines unless those services are installed manually. A change that passes one dialect can still fail another, so application teams should run their own query and migration suite against the same database version used in production.
What happened when we ran it
Our sandbox installed 1,425 Yarn packages in 80 seconds and consumed 721 MB on disk. The run used commit 704b36e in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The repository scan found nine CI workflow files, a tests directory, and monorepo workspaces. Our test method followed the root commands exposed to the harness; it did not provision Postgres, MySQL, or the other external database services described in the contributor guide.
The build ran for 64 seconds and exited with code 1. Lerna reported that 13 project builds were attempted and @sequelize/cli:build failed. The final error said /lib/x86_64-linux-gnu/libm.so.6 lacked GLIBC_2.38, which was required by node_modules/sqlite3/build/Release/node_sqlite3.node. The log does not say the TypeScript source was broken. It says the installed native SQLite module could not load against the container's C library.
No root test script or target matched the harness, so the test step was skipped. That is not evidence that Sequelize has no tests: the checkout had a tests directory, and package manifests expose unit, typings, export, and dialect integration commands. It means this run produced no pass count to report. A meaningful contributor check must select a package and dialect, build first, and provide any database service that suite needs. The nine CI workflows are another reason to inspect upstream jobs before copying a single local command.
Issue 18207 makes nested savepoints an adoption test
Issue 18207 reproduces three nested-savepoint problems in Sequelize 6.37.8 with Postgres, and says one name-collision pattern also exists on version 7 main. The report describes duplicate savepoint names across nesting levels, which can target the wrong savepoint during rollback. Pull request 18236 proposes unique names and includes a unit test, but it was still open when checked. Teams that depend on nested transaction wrappers should reproduce their exact flow and pin a version with the required fix instead of assuming transaction support covers every nesting pattern.
Another open report, issue 11325, says a dependency of a VIRTUAL attribute can be selected even when that field appears in attributes.exclude. Its example involves a verification hash, so the conservative lesson is specific: select only intended public fields and test the serialized response. GitHub listed 1,079 combined issues and pull requests, not 1,079 confirmed bugs. The September 2, 2026 push and active dependency and transaction work show current maintenance despite the large queue.
Thirty thousand stars do not finish the version 7 transition
GitHub recorded 30,373 stars, and stable release 6.37.8 shipped a security fix for JSON where-clause cast validation on March 7, 2026. The repository was pushed on September 2, so the older stable tag is not evidence of abandonment. The more important governance signal is in the README: the project is seeking new maintainers to finish the next major and offers funding. Existing version 6 users have a maintained line; version 7 adopters are participating earlier in the lifecycle.
The choice depends on how much abstraction your team wants. Prisma ORM uses a generated client and schema. TypeORM leans into entities and decorators. Knex stays closer to SQL. Sequelize sits between those styles with runtime models, broad dialect support, and long-standing documentation. Our failed 64-second build lowers confidence in a frictionless contributor setup, though it does not cancel the value of the stable package. For production, choose version 6 deliberately, pin the connector, and test generated SQL, transactions, migrations, and field projection on the real dialect.