Drizzle

Why it's ranked here

The case for including it is in the type system, not the marketing copy. Nested join results that null-check per table, rather than one merged row you have to guess about, is a real engineering choice with tradeoffs, and the source code backs it up rather than just the README claiming it. Dialect support spans mainstream relational databases as well as several serverless drivers, handled through one configuration surface rather than separate adapters. That breadth, paired with a documented pattern for adding new column types, is what earns this a spot over a simpler query builder.

What's good

Joins are the standout: instead of flattening a join into one row with nullable fields you must check individually, results nest by table so a single null check covers every field from that side of the join. Adding a new column type follows a documented, consistent pattern: a builder class and a column class per dialect, so the extension surface is explicit rather than something you reverse-engineer from the core library. The migration CLI covers the full loop, generating SQL files, applying or pulling schema, and inspecting data, rather than stopping at code generation.

Tradeoffs

The migration CLI's configuration type is sprawling: separate credential shapes for AWS's data API, Cloudflare's SQLite service, Expo, PGlite, and a couple of others, each mutually exclusive with the rest, so picking the right combination for a given serverless target takes real reading. Custom column types tied to database extensions are explicitly flagged as not yet supported, only worked around with examples. Several old per-dialect command names survive only as hidden aliases that print a deprecation notice, a sign the CLI's interface has already changed shape once and may again.

How to use it well

This fits teams building a TypeScript backend who want the compiler to catch a mismatched join or a missing column before it hits production, especially across more than one deployment target such as an edge runtime and a traditional server. Define the schema once, use the CLI to generate and apply migrations as part of the normal deploy flow, and reach for the bundled data browser for quick manual checks instead of a separate admin tool. It is not a drop-in replacement for a full database administration console, and picking the right driver configuration for a serverless database still requires reading the specific dialect's setup docs closely.

Observed

Packaging

Ships as two separate packages: a core ORM library and a companion CLI for migrations, run from one monorepo built with pnpm workspaces and Turborepo

Packaging

The root package is marked private; only the sub-packages are published

CLI commands

CLI commands cover the full migration lifecycle: generating SQL migration files, applying or pulling schema against a live database, and a bundled data-browsing tool

Dialect support

Configuration types support Postgres, MySQL, SQLite, and SingleStore dialects, plus dedicated drivers for AWS Data API, Cloudflare D1, Turso, Expo, and PGlite

Query results

Query builder returns join results as nested per-table objects rather than one flattened row, so nullability is checked once per joined table instead of per column

Extensibility

Adding a new column type follows a documented builder-class-plus-column-class pattern that is dialect-specific (separate implementations for Postgres, MySQL, and SQLite)

CLI compatibility

Several legacy per-dialect CLI command names are retained only as hidden aliases that print a deprecation message pointing to their replacement

Limitations

Custom column types tied to database extensions are documented as not yet supported, with only manual workaround examples provided