Drizzle ORM Guidelines

Reference Repositories

• Drizzle ORM : TypeScript ORM with SQL-like query builder
• Turso : Edge-hosted LibSQL database (Epicenter's database)

Upstream Grounding

When Drizzle schema definitions, migration snapshots, query builder APIs, column typing, custom types, or driver integration affect correctness, use source-backed grounding before relying on memory. If DeepWiki MCP is available, ask a narrow question against drizzle-team/drizzle-orm; for libSQL, Turso sync, embedded replicas, D1 compatibility, or remote SQLite behavior, ask against tursodatabase/turso. If DeepWiki is unavailable or the repo is not indexed, use upstream source or official docs directly. Treat DeepWiki as orientation, then verify decisive details against local installed types, generated migrations, source, driver versions, or official docs before changing code.

Skip DeepWiki for repo-local schema naming and storage-boundary conventions already documented below.

Schema And Migration Rules

• Export a single schema object from the app's database module and pass that same object to drizzle(...) and Drizzle Kit config.
• Keep table definitions, relations, and schema exports explicit. Avoid dynamic schema construction that Drizzle Kit cannot statically inspect.
• Treat Drizzle Kit snapshots as the diff source of truth. Review generated SQL and snapshot changes together.
• Pick a casing strategy once per database. Do not mix app-level camelCase with ad hoc SQL aliases unless the boundary owns that mapping.
• Use drizzle-zod, drizzle-valibot, or a local schema parser at IO boundaries when external input becomes a row. Do not treat inferred insert types as runtime validation.