Drizzle ORM 0.45

DZ-C02 · drizzle-kit commands do not carry database passwords (--password, user:password@ URLs)

DZ-C02 · Database passwords (connection strings, connection option objects) are not written into source or config; placeholders and application passwords pass

DZ-Q11 · Whole-row reads of tables holding secrets (password, token, secret…) select explicit fields

DZ-Q01 · Values reach SQL as parameters: no dynamic text in sql.raw() or untagged strings passed to execute()

DZ-Q02 · Table, column and sort choices from untrusted input go through a closed mapping, not table[input] or sql.identifier(input)

DZ-Q05 · Untrusted request objects are not passed or spread whole into .values()/.set(): writable fields are allowlisted

DZ-Q14 · limit/offset taken from untrusted input are bounded and validated

DZ-C06 · On a shared database (sharedDatabase), push and pull are restricted with tablesFilter/schemaFilter

DZ-M04 · Generated migration SQL that drops, renames, narrows or adds constraints is reviewed before it is applied

DZ-M04 · drizzle-kit push --force (auto-approves data-loss statements) needs the user's confirmation

DZ-M05 · Deleting or rewriting recorded migrations (drizzle-kit drop, rm/mv/git rm in the migrations folder) needs the user's confirmation

DZ-Q03 · An executed Drizzle update or delete has a where predicate, unless the bulk write is a recorded exception

DZ-Q04 · A mutation's where argument is not typed SQL | undefined (language server: variables and helper results)

DZ-Q04 · A mutation's where predicate cannot collapse to undefined (all-optional and()/or(), undefined) or a tautology

DZ-A08 · Drizzle type errors are fixed, not suppressed with @ts-ignore, @ts-expect-error or @ts-nocheck

DZ-Z03 · Exception markers (// dz-<rule>:) name one rule and give a reason; no blanket disabling of the profile

DZ-A04/A08 · Drizzle tables, columns and results are not erased to any (casts, any-typed generic CRUD wrappers)

DZ-A07 · Query failures are not turned into empty results or defaults ([], null, {}, 0, false) that callers cannot tell apart

DZ-C07 · Database clients and pools are created once per lifecycle, not inside query functions

DZ-Q16 · Queries that depend on each row of a loop are reviewed for N+1 (join, relational query, inArray batch)

DZ-Q17 · Unfiltered reads are not followed only by JavaScript filtering, counting or summing (push it into SQL)

DZ-Q20 · Several new indexes at once are justified by observed query plans (hint)

DZ-A01 · Schema modules stay declarative: no client, driver, framework, env or app-entry imports

DZ-A02 · Drizzle queries run only in the modules the project declares for data access (parameter dataAccessPaths)

DZ-A03 · A predicate repeated three times or more in a file (tenant, soft delete, ownership) becomes one small typed helper; primary-key lookups and join conditions are not scope filters

DZ-A05 · No speculative scaffolding: new private query helpers have a caller in the file

DZ-Q06 · Predicates are combined explicitly: a second .where() on the same builder replaces the first

DZ-Q07 · Mutable query builders are created per call, not kept at module level and modified by functions

DZ-Q08 · Optional read filters are composed into one query instead of duplicated if/else chains (hint)

DZ-Q09 · Null tests use isNull/isNotNull, not eq/ne(column, null) or = NULL in SQL

DZ-Q10 · sql<number> over count/sum/avg on PostgreSQL decodes the value (mapWith, cast, count()) instead of claiming a type

DZ-Q12 · SQL fields selected in a subquery or CTE carry an alias (.as) before they are referenced outside it

DZ-Q13 · Paginated reads (offset) have an orderBy, so pages are deterministic

DZ-Q15 · The first row of a select or a findFirst result is checked for absence before it is dereferenced

DZ-Q18 · Insert-or-update is atomic: no existence check followed by insert/update without conflict handling or locking

DZ-Q19 · Drizzle mutations reach execution: a builder statement without await/return never runs; .execute() is awaited

DZ-R01 · one() relation mappings pair fields of the declaring table with as many references of the target table

DZ-R02 · Several relations between the same two tables are disambiguated with relationName

DZ-R03 · Relational queries keep offset at the root: 0.45 types nested with-configs without offset

DZ-R04 · Relational extras hold aliased per-row SQL, not aggregates (count/sum/… need a subquery or a core query)

DZ-R05 · A nested with-where filters children, not parents (hint once per session)

DZ-S01 · One declaration per table and per column name: no second table with the same SQL name, no repeated column name

DZ-S03 · New tables have a primary key (keyless only for intentional append-only, import or log tables)

DZ-S04 · relations() is not a foreign key: a one() over a column without references()/foreignKey() is flagged

DZ-S05 · A join table of two foreign keys has a composite primary key or unique constraint over the pair

DZ-S06 · ON DELETE/UPDATE SET NULL only targets nullable columns

DZ-S07 · $defaultFn/$onUpdate are application-side only: no DDL, ignored by other writers (hint once per session)

DZ-S08 · Inserts and updates do not turn an absent value into null (?? null), which overrides defaults and NOT NULL

DZ-S09 · Row types are inferred from the table ($inferSelect/$inferInsert), not mirrored by hand next to it

DZ-S10 · .$type<T>() and text enums are compile-time hints, not validation (hint once per session)

DZ-S11 · bigint/numeric columns are not decoded as JavaScript number without a stated range

DZ-S13 · Repeated JSON/Date conversions of query values are centralized (customType, mapWith or one helper)

DZ-S14 · Extension-dependent columns and indexes (pgvector, PostGIS, pg_trgm) come with a CREATE EXTENSION migration

DZ-X01 · Several awaited writes in one function run in a transaction when they form one change

DZ-X02 · Queries inside a transaction callback use its tx handle, not the outer database handle

DZ-X03 · A failed write inside a transaction is rethrown or rolled back, never caught into a normal return

DZ-X04 · Irreversible external effects (HTTP, mail, queues, payments) are kept out of transaction callbacks

DZ-X05 · Counters and balances are updated in SQL, not read into JavaScript, changed and written back

DZ-M01 · Schema changes follow the declared workflow (migrationWorkflow): no push for migrations, no generate for push, nothing for external

DZ-M02 · push on a project that records migrations (a journal exists, workflow not declared) needs the user's confirmation

DZ-M03 · A turn that changes table/column/index declarations in a migrations project also generates the migration (once per stop)

DZ-M05 · Committed migration SQL files are not edited or rewritten (add a forward migration instead)

DZ-M06 · A new SQL file in the migrations folder comes from drizzle-kit generate --custom (the journal registers it)

DZ-M08 · drizzle-kit check warnings (entries the migrator would skip, collisions, malformed snapshots) are unresolved findings

DZ-M09 · Journal entries keep strictly increasing when timestamps in entry order (merges of parallel branches included)

DZ-M11 · migrate() has one execution owner: not in request handlers or every server/worker start without a lock

DZ-T09 · Applying migrations uses drizzle-kit migrate or the driver's migrate(), not a hand-written journal reader or ledger

DZ-V01/Z04 · At session start, Claude learns the installed drizzle-orm/drizzle-kit versions and whether this profile's 0.45/0.31 rules apply

DZ-V02 · Drizzle 1.0 relational APIs (defineRelations, db._query, r.one/r.many, object where/orderBy) stay out of 0.45 code

DZ-V03 · drizzle-orm subpath imports exist in the installed package (no 1.0-only drizzle-orm/zod, /valibot, /_relations…)

DZ-V04 · PostgreSQL indexes use the 0.31+ API: ordering and nulls on each column, using(method, …columns)

DZ-V05/V12 · New code avoids APIs drizzle-orm 0.45 marks deprecated (InferModel, placeholder/param/name, fromList, positional primaryKey…)

DZ-V05 · No new call resolves to a deprecated Drizzle overload (language server: table extra config, keys, conflict targets, aliases)

DZ-V05 · Table extra configuration returns an array (the object form is deprecated in 0.45)

DZ-V06/V07 · drizzle-kit is called with commands and flags of the installed 0.31 CLI (no generate:pg, no 1.0 beta commands or flags)

DZ-V08 · Named .prepare() is not used where server-side prepared statements are declared unsupported (postgres-js prepare: false, poolers)

DZ-V09 · Identifiers and aliases are escaped by Drizzle (sql.identifier, .as), never quoted or escaped by hand

DZ-V10 · drizzle() for mysql2 gets a relational mode (default or planetscale) whenever it gets a schema

DZ-V11 · MySQL and SingleStore inserts/updates/deletes do not use .returning(); $returningId() returns generated keys only

DZ-V12 · Valid older schema syntax is not rewritten without a defect: explicit column names and serial columns stay as written

DZ-C01 · drizzle.config keys and values exist in drizzle-kit 0.31 (dialect set and valid, no legacy driver/connectionString, no unknown keys)

DZ-C02 · Runtime clients validate required connection settings at initialization instead of asserting process.env.X!

DZ-C03 · Tables, enums and views in the config's schema files are exported, and new table files are inside the schema globs

DZ-C04 · db.query is used only on a drizzle() instance created with the schema (tables and relations)

DZ-C05 · The runtime drizzle() casing matches drizzle.config casing, so queries and migrations name columns alike

DZ-C08 · No interactive transaction on drivers that throw on it (neon-http, xata-http): use batch() or a session driver

DZ-T01 · A new package.json without dependencies is initialized with the package manager

DZ-T01/T02 · A new package.json comes from the package-manager initializer (or a generator), and gets its dependencies from the package manager

DZ-T02 · Dependencies change through the package manager (add/remove/update), never by editing package.json by hand

Records the tool calls that run a package manager (they may rewrite package.json and lockfiles; DZ-T02/T03)

DZ-T02 · Registry version lookups are not a step before installing

DZ-T02 · Packages are installed by name: no guessed exact version, no --save-exact without a reason

DZ-T03 · Lockfiles are written by the package manager only (no hand edit, no script rewriting them)

DZ-T03 · After an install that touched drizzle packages, the resolved versions are still on this profile's line

DZ-T03 · A turn that changes package.json dependencies also updates the lockfile next to it (once per stop)

DZ-T04 · Dependencies are installed with the project's package manager (packageManager field, lockfile)

DZ-T04 · No second lockfile next to another package manager's lockfile

DZ-T05 · drizzle-kit runs from the project (script or local binary), not from a downloaded or global copy

DZ-T06 · drizzle-orm and the driver are runtime dependencies, drizzle-kit a dev dependency; only the selected driver is installed

DZ-T10 · CI and container builds restore dependencies from the lockfile (npm ci, --frozen-lockfile, --immutable)

DZ-V01/V02 · drizzle packages are not installed at a 1.0 beta/RC tag or a version below this profile's line

DZ-M10 · The __drizzle_migrations ledger is never written by hand (no synthetic insert, update or delete of applied rows)

DZ-T07 · A schema for an existing database is pulled with drizzle-kit, not transcribed by hand from introspection output

DZ-T08 · Migration journals and snapshots are written by drizzle-kit (or git), never by hand or by a script

Records the tool calls that run git (checkouts and merges rewrite migration metadata legitimately; DZ-T08)

Records drizzle-kit runs: the call (for migration files it writes, DZ-T08/M06) and the turn's ledger of kit verbs (DZ-M07, M13)

Records, per turn, the drizzle-kit verbs and migration runs that succeeded (DZ-M07, M13)

DZ-M07 · drizzle-kit up (snapshot format upgrade) is not reported as applying migrations to a database (once per stop)

DZ-M12 · push/migrate output reporting an error or an abort is treated as a failure even when the exit code is 0

DZ-M13/Z02 · A turn that adds migrations shows them applied somewhere (migrate, push to a scratch database, or a test) before ending (once per stop)

Records the work tree when a prompt starts: the baseline of the Drizzle end-of-turn checks (DZ-T03, M03, M13, Z01)

Records, per session, Claude's edits (file tools and shell writes) and the typecheck, lint and test runs that succeeded after them (DZ-Z01, M13)

DZ-Z01/A08 · A turn adds no TypeScript errors to the changed files or their importers (language server, once per stop)

DZ-Z01 · A turn that changed Drizzle code ends only after the configured checks (default: typecheck) succeeded on the final files (once per stop)