balligh-insage/claida-drizzle-rules icon
public
Published on 3/6/2025
balligh-insage/claida-drizzle-rules

Rules
  • Always associate data with an account_id and ensure queries filter by the correct account_id.
  • For personal accounts, the user is the sole owner. For team accounts, memberships define access.
  • RLS Policies must be respected on each table.
  • Use getDrizzleSupabaseClient() for RLS-protected queries.
  • Use getDrizzleSupabaseAdminClient() only for admin or special-privilege operations (use sparingly).
  • Keep code in server-side or React Server Components whenever possible to minimize 'use client'.
  • Define tables with Drizzle's Postgres helpers.
  • Keep table definitions in sync with your Postgres schema (including indexes, constraints).
  • Use InferModel<typeof table> for type-safe operations.
  • Leverage this in queries, mutations, and server actions to avoid manual type declarations.
  • Prefer short, transactional operations.
  • Tag new rows with account_id to maintain tenant isolation.
  • Wrap critical operations in try/catch.
  • Return clear error messages. Use guard clauses for invalid states.
  • Minimize round trips to the database by batching queries in transactions.
  • Rely on RLS policies to restrict unauthorized access.
  • Handle admin queries with extreme caution.
  • Carefully structure each query/transaction, ensuring it respects RLS and references correct account_id.
  • Evaluate multiple approaches (e.g., standard vs. admin client), choose the one that maintains secure multi-tenancy.
  • Before finalizing, review code for type safety, RLS compliance, and clear error handling.
  • Follow these Drizzle ORM and RLS best practices to maintain a secure, robust, and easily maintainable multi-tenant solution.
  • Always validate data paths, wrap queries in transactions, and ensure each resource is correctly tied to account_id.
  • If a requirement or scenario conflicts with these rules, explicitly document the trade-offs or disclaimers in your response.