Sequelize v6 is stable and v7 is still alpha, and the README says so outright

The maintainer recruitment notice sits above the getting started links

The README leads with a notice seeking new maintainers to finalise and release the next major version, and it appears before the getting started section. The stated work is finalising and shipping the next major version, improving TypeScript support and database integrations, and fixing critical issues while shaping the future of the ORM. Funding is described concretely: $2,500 per quarter distributed among maintainers, with additional funds available for full-time contributions. Two named maintainers are given as the contact, and the call to action points at the project Slack. This placement is deliberate. A reader arriving at the repository is told about the project's staffing situation before they are told how to install it, which is an unusual amount of prominence for a governance note and a fair signal about the maturity of the release line.

Two version lines are documented in parallel, and one is labelled alpha

The getting started section offers two guides rather than one. There is a guide for Sequelize 6 marked as stable, and a separate guide for Sequelize 7 marked as alpha. The same split reappears further down, where upgrade information is listed as two separate documents: one for upgrading from v5 to v6, and one for upgrading from v6 to v7. That second document is the one to read before adopting v7, because it is the project's own account of what breaks. The published releases show the same picture. The most recent tagged stable is v6.37.8, while the v7 line exists as a run of alpha builds. So a new project has a supported path and an unfinished one, and the README keeps them clearly labelled rather than presenting v7 as the current recommendation.

One integration test script per database engine, and the engines are enterprise-heavy

The engine list is not a set of hobby databases either: alongside the usual open source engines it covers Oracle, DB2, DB2 for IBM i, Snowflake, and Microsoft SQL Server. Postgres appears twice, once as a plain integration suite and once labelled native, which reflects two bindings rather than one and means the native path is tested independently of the default one. Snowflake and IBM i are the entries most likely to surprise someone reading the engine list casually, because neither is a conventional self-hosted relational server you would run on a laptop. SQLite 3 sits at the other end as the embedded option. The unit suite is structured differently again, running one ESM named exports test directly and then delegating the rest of the unit tests to the monorepo task runner, so the module shape is checked once at the root and the package tests run per package.

The published package is a subset of the monorepo, and the root is private

The repository is a monorepo, and its root package is marked private, which means it is not itself installable. The npm badges at the top of the README point at a scoped package under the project namespace rather than at the repository name, so the distributed artifact is one package inside the tree rather than the tree itself. Publishing is handled by a task runner invoking a conventional-commits release flow that creates the GitHub release as part of the publish, so the tag and the release entry are produced together rather than by hand. A separate build script drives the build across packages. Documentation is generated with a typed documentation generator configured by two separate files at the root, one of which is a shared base config, which is how the same API docs are produced for several packages with consistent settings. Two type-check entry points exist alongside the unit tests, one that runs a typings test and one that runs an exports test, which is the pattern that catches a package whose public surface changed without its types following.

Migrations live in a separate repository, not in this one

The single most common Sequelize task has its own home. The tools section of the README lists a CLI as a separate repository rather than as a package inside this monorepo. That is the migration and seeding tool, and it is installed and versioned independently from the ORM itself, which means the two can drift apart. The tools section also lists adapters maintained elsewhere for GraphQL, for CockroachDB, and for YugabyteDB. So the supported database story is not closed: the core repository names the engines it ships tests for, and third parties extend the set. An unofficial Chinese translation of the documentation is also listed and marked as such, which is worth knowing before searching for guides and finding a version that lags the official text.

Formatting and linting are two separate passes with a check mode for each

The scripts are arranged so that fixing and checking are separate commands with matching names. Formatting runs the linter with a fix flag first and then runs a separate formatter in write mode, so the two tools are applied in sequence rather than merged. The matching check commands exist for both, and a top-level test script runs every format check concurrently. The linter invocation carries a flag that reports unused disable directives, which means a suppression comment left behind after the underlying problem was fixed becomes a failure rather than dead configuration. A markdown lint configuration and a prettier configuration sit at the root alongside a prettier ignore file, so documentation files are held to the same standard as source. An editor config file is present as well, which keeps indentation consistent for contributors who have not matched the project settings.

Support is pooled by contribution, not assigned by company

Funding runs through an OpenCollective pool, and the README describes how the money is divided: the pool is shared among all core maintainers based on their contributions. The maintainer notice separately mentions $2,500 per quarter distributed among maintainers, and the README does not say whether that money comes from the same pool. Contributions are also organized through contribution guidelines at the root, with a separate document covering contributions to the documentation specifically. A contact file and a code of conduct file sit alongside them. Security issues are handled through a responsible disclosure policy linked from the README, so a vulnerability report does not go through the public issue tracker.

Editorial conclusion

Sequelize suits a Node.js team that needs one ORM across several database engines, since read replication and relations are part of the feature set rather than an add-on. Two things to weigh first. Version 7 is alpha, so committing to it means committing to an API that the upgrade guide still has to finalise, and the project is actively recruiting maintainers to finish it, which tells you where the risk sits. Second, the engine list is a promise you should verify against the compatibility table rather than assume, since each engine has its own integration suite.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sequelize/sequelize on GitHub