drizzle-orm-patterns

A comprehensive reference for building type-safe database applications with Drizzle ORM, covering schema definition, CRUD operations, relations, queries, transactions, and migrations across PostgreSQL, MySQL, SQLite, MSSQL, and CockroachDB. It is meant to be used proactively for any Drizzle development, from defining schemas with tables, columns, and constraints to writing type-safe queries, implementing relations, managing transactions, and setting up migrations with Drizzle Kit. Quick-reference tables map each database to its table function and import path (for example pgTable from drizzle-orm/pg-core) and list the core operations: db.insert(), db.select(), db.update(), db.delete(), and db.transaction().

The recommended workflow is to identify the database dialect, define the schema with the appropriate table function, set up relations using relations() or defineRelations(), initialize the Drizzle client with proper credentials, write queries with the type-safe query builder, wrap multi-step operations in transactions when needed, and configure Drizzle Kit for migrations. Worked examples show a basic schema with pgTable and a typed select, insert/update/delete with returning() and eq() filters, and a transaction that reads balances, calls tx.rollback() when funds are insufficient, and updates balances with a sql template expression.

Best practices emphasize leveraging $inferInsert and $inferSelect for type safety, defining relations for nested queries, using transactions for operations that must succeed together, choosing generate plus migrate in production versus push in development, indexing frequently queried columns and foreign keys, preferring soft deletes via a deletedAt timestamp, and using cursor-based pagination. Constraints and warnings note that references should be defined with arrow functions to avoid circular dependencies, that tx.rollback() throws an exception, that not all databases support returning(), that large batch inserts may hit database limits, and that migrations should be tested in staging first. Additional reference files cover schema definition, relations with v1 and v2 syntax, queries and joins, transactions, migrations, and common patterns such as upsert, full-text search, and audit trails.