- 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.