Kysely vs SQLAlchemy
Kysely and SQLAlchemy both answer the same question: how does your code talk to the database? A type-safe SQL query builder rather than an ORM, for people who want SQL with autocomplete. The Python data access standard outside Django, giving you a full ORM layered on a serious SQL toolkit. Kysely covers more of the ecosystem, so it survives a change of framework; SQLAlchemy is the better fit while you stay where it is strongest.
Verdict
Kysely covers more of the ecosystem, so it survives a change of framework; SQLAlchemy is the better fit while you stay where it is strongest.
Pick Kysely if
- ✓You write SQL semantics directly, so nothing surprising reaches the database.
- ✓Types come from your database schema, catching column typos at build time.
- ✓Tiny surface area, so it composes with whatever migration tool you prefer.
Pick SQLAlchemy if
- ✓The Core layer lets you drop to composable SQL expressions when the ORM fits badly.
- ✓Unit of work session model handles complex object graphs correctly.
- ✓Two decades of production use across very large Python codebases.
| Comparison | Kysely | SQLAlchemy |
|---|---|---|
| Pricing shape | Free and open source, with no hosted component to buy. | Free and open source, with no commercial tier. |
| Frameworks | Next.js, SvelteKit, Nuxt | Django |
| In one line | A type-safe SQL query builder rather than an ORM, for people who want SQL with autocomplete. | The Python data access standard outside Django, giving you a full ORM layered on a serious SQL toolkit. |
Pricing described qualitatively because published plans change often. Checked 2026-08-23. Confirm current terms on Kysely and SQLAlchemy.
Kysely
Strengths
- ✓You write SQL semantics directly, so nothing surprising reaches the database.
- ✓Types come from your database schema, catching column typos at build time.
- ✓Tiny surface area, so it composes with whatever migration tool you prefer.
- ✓Plugin architecture makes custom dialects and naming conventions straightforward.
Tradeoffs
- ✗No entity model or change tracking, since it deliberately stops at queries.
- ✗Migrations and schema types are separate concerns you must wire together.
- ✗Relation loading is manual, so nested reads take deliberate assembly.
- ✗Requires people on the team who are comfortable reading real SQL.
SQLAlchemy
Strengths
- ✓The Core layer lets you drop to composable SQL expressions when the ORM fits badly.
- ✓Unit of work session model handles complex object graphs correctly.
- ✓Two decades of production use across very large Python codebases.
- ✓Alembic gives migrations that handle genuinely complicated schema evolution.
Tradeoffs
- ✗Python only, so it is irrelevant to a TypeScript-first stack.
- ✗Django projects already ship an ORM, making this a redundant second one.
- ✗The learning curve for sessions and identity maps is famously steep.
- ✗Async support arrived later and still has sharp edges around lazy loading.
Frequently asked questions
Is Kysely or SQLAlchemy better?
Neither is better in the abstract. Kysely covers more of the ecosystem, so it survives a change of framework; SQLAlchemy is the better fit while you stay where it is strongest. Pick the one whose downside you can absorb, because both upsides are real.
What is the main drawback of Kysely?
No entity model or change tracking, since it deliberately stops at queries. Migrations and schema types are separate concerns you must wire together.
What is the main drawback of SQLAlchemy?
Python only, so it is irrelevant to a TypeScript-first stack. Django projects already ship an ORM, making this a redundant second one.
Can you switch from one to the other later?
Usually, at a cost that grows with how much of your product leans on the orm and query layer layer. Plan for it in the data model, not in the framework, and the switch stays survivable.