This section documents version-specific API changes — prioritize recent major/minor releases.
-
BREAKING: drizzle-kit migrations folder structure changed — journal.json removed, SQL files and snapshots grouped into separate migration folders, and drizzle-kit drop command removed. This affects migration workflow. source
-
BREAKING: Validator packages imports changed — drizzle-zod, drizzle-valibot, drizzle-typebox, drizzle-arktype are no longer separate packages. They are now imported directly from drizzle-orm (e.g., drizzle-orm/zod). source
-
BREAKING: Relational Queries V1 to V2 migration — significant changes in how relations are defined and queried. This includes the introduction of defineRelations and changes to where and orderBy syntax. source
-
BREAKING: Relations Schema Definition changed — previously, relations were specified per table; now defineRelations allows defining all relations in one place. source
-
BREAKING: drizzle() mode option removed — mode: "planetscale" or mode: "default" are no longer needed for MySQL dialects. source
-
BREAKING: fields and references renamed to from and to — in one and many relation definitions. source
-
BREAKING: relationName renamed to alias — in one relation definitions. source
-
BREAKING: where statements in queries changed from function to object syntax (e.g., where: { id: 1 }). source
-
BREAKING: orderBy statements in queries changed from function to object syntax (e.g., orderBy: { id: "asc" }). source
-
BREAKING: db.query now refers to RQBv2 syntax, RQBv1 syntax moved to db._query. source
-
BREAKING: Internal type signature changes — migrator, session, transaction, driver, and DrizzleConfig now include TRelations and TTablesConfig generic arguments. source
-
BREAKING: Entities like Relation, Relations, One, Many moved from drizzle-orm to drizzle-orm/_relations. source
-
BREAKING: dialect-core/query-builders/query files moved to dialect-core/query-builders/_query (e.g., RelationalQueryBuilder to _RelationalQueryBuilder). source
-
NEW: defineRelations and defineRelationsPart functions introduced for defining relations. source
-
NEW: Simplified many relation definition without requiring a one on the other side. source
-
NEW: optional option in relation definitions to make related entities required at the type level. source
-
NEW: fromJson and forJsonSelect functions for custom types to control data mapping in relational queries. source
-
NEW: through for many-to-many relations for simplified definition of complex relationships. source
-
NEW: Predefined filters in relations for adding where clauses directly in relation definitions. source
-
NEW: Filtering by relations allows filtering main query results based on related object conditions. source
-
NEW: Using offset on related objects for applying offset to with clauses in queries. source
-
NEW: drizzle-kit pull now supports generating relations.ts in the new v2 syntax. source
-
NEW: Export of additional types from SQLite package, like AnySQLiteUpdate. source
-
Use relational queries for efficient querying of nested relational data, avoiding multiple joins and complex data mappings. source
-
Leverage the ESLint plugin for recommended rules to assist developers in handling crucial scenarios where type checks are impossible or error messages are challenging to understand. source
-
Configure drizzleObjectName in the ESLint plugin options to prevent false positives when other objects or classes have methods named delete or update. source
-
Prefer PostgreSQL Identity columns over the deprecated serial type for specifying sequences in your schema. source
-
Utilize nested select object syntax in joins to avoid a plethora of nullable fields and ensure smart type inference makes the whole object nullable, not individual fields. source
-
For JSON data in SQLite, use text('', { mode: 'json' }) instead of blob('', { mode: 'json' }) as it supports JSON functions. source
-
When dealing with many simultaneous connections to PlanetScale Postgres, route connections via PgBouncer on port 6432 for efficient connection pooling. source
-
Implement recommended indexing strategies for relations to optimize database performance in applications with significant data or complex queries. source
-
For many-to-many relationships, create indexes on each foreign key column individually within the junction table to optimize queries based on a single side of the relationship. source
-
Avoid using the datetime data type in MSSQL for new work; instead, use time, date, datetime2, and datetimeoffset for better portability, precision, and time zone support. source
-
In larger Effect applications, create a reusable DB layer for dependency injection, adhering to Effect’s recommended pattern. source
-
Avoid the undefined drizzle({} as any) API for mocking; use the proper drizzle.mock() API instead. source
-
When using upsert clauses in a SELECT statement, always include a WHERE clause (even WHERE true) to avoid parsing ambiguities. source
-
Employ stored (or persistent) generated columns to improve query performance, as their values are stored and indexed, eliminating the need for recomputation on each query. source