Cursor Rules for Database Work: Schema, Queries, and Changes

Cursor rules for database work tell the assistant which changes to the schema require human review, which query patterns are approved, how migrations are managed, and which operations must not be run automatically. Database changes are among the hardest to reverse — a dropped column or a data migration that runs against a large table in production can cause downtime or data loss. Rules that name the approved procedures and explicit constraints protect against an assistant treating a destructive database change with the same confidence as a code refactor. fenbs records the decisions and approvals that the rules refer to, so every connected assistant understands not just what the rules say but why they exist.

The templates below assume a relational database. Adapt them to your actual database system, migration tool, and team conventions before using them.

Schema ownership and change rules

The most important database rule is who owns schema changes and what the approval process is. An assistant that generates a migration to add a column or change a type needs to know whether that change can go directly into a branch or requires a DBA review. A rule that names the process prevents the assistant from treating a schema change as routine when it requires approval.

Schema changes:
- All schema changes go through migration files (never modify tables directly)
- Migrations live in db/migrations/
- Adding a nullable column: branch + pull request, no DBA review needed
- Adding a non-nullable column: requires a default value OR a two-step migration
  (add nullable, backfill, add constraint); requires DBA review
- Dropping a column or table: requires DBA review and a confirmed backup
- Index additions on large tables: reviewed for performance impact before applying

Do not run migrations against production without the deployment checklist.

Query pattern rules

Approved query patterns depend on the ORM or query builder your project uses, the size of the tables involved, and the performance constraints of the service. A rule that names the approved patterns and the ones to avoid prevents the assistant from writing a query that looks correct but causes a full table scan in production.

Query rules:
- Use parameterized queries for all user input — never use string concatenation
- Always select only the columns you need (SELECT col1, col2, not SELECT *)
- Filter on indexed columns where possible; flag unindexed filters on large tables
- Avoid N+1 patterns: batch related data with JOIN or IN rather than per-row queries
- For bulk operations, use batch INSERT/UPDATE rather than per-row calls
- Pagination: use keyset pagination on large tables, not OFFSET on large offsets

Migration management rules

Migrations need rules about how they are created, reviewed, and applied, especially in a team where two people might create a migration at the same time. A rule about naming, sequencing, and the review process prevents the most common migration conflicts.

Migrations:
- File naming: YYYYMMDDHHMMSS_description.sql (timestamp prefix)
- One migration per branch; resolve conflicts before merging
- Never edit a migration after it has been applied in any shared environment
- Rollback scripts: write a corresponding down migration for every up migration
- Test migrations on a copy of the production schema before applying
- Apply in order: migrations must be applied in the sequence they were created

Destructive operation rules

DROP TABLE, TRUNCATE, and UPDATE without a WHERE clause are the operations most likely to cause irreversible data loss. A rule that makes these require explicit approval and a verified backup prevents the assistant from including them in an automated change without flagging the risk.

Operations requiring explicit approval:
- DROP TABLE or DROP COLUMN: confirm the data is no longer needed and is not referenced
- TRUNCATE: confirm the table is safe to empty in this environment
- UPDATE without a WHERE clause: flag for review; always add a WHERE clause
- DELETE without a WHERE clause: never acceptable; always add a WHERE clause

Before any destructive change in staging or production:
1. Confirm a backup is available and restorable
2. Get approval from a team lead
3. Run in a transaction where possible (can be rolled back if wrong)

Access and credential rules

Database credentials should never appear in code or in rule files. A rule that names where credentials come from and how the application connects to the database prevents the assistant from hardcoding a connection string or suggesting an approach that exposes credentials.

Database credentials:
- Connection string comes from the DATABASE_URL environment variable
- Never hardcode credentials in source code, config files, or migration scripts
- The application connects as the app user (limited permissions)
- Migrations run as the migrations user (can ALTER TABLE)
- Production credentials are managed by the platform and are not shared
  with developers

How to do this with fenbs

1. Create a free account and add a project for the service that owns the database.
2. Record each database policy in Decisions and rules: the migration process, which operations require approval, the query patterns that are forbidden. Note the person who approved each rule.
3. When a database incident occurs — a slow query, a migration conflict, an accidental data loss — add a lesson in fenbs: what happened, what the correct approach is, and what to watch for. These lessons become the source material for future rule updates.
4. Add the approved change procedures as skills or prompts in fenbs so the assistant can follow the correct steps when working on schema changes.
5. Connect your AI tools from Integrations so they read the current database policies before starting any work that touches the schema or data.

What rules cannot prevent

Cursor rules guide the assistant's behavior but they do not prevent it from generating incorrect SQL or suggesting an approach that happens to match a harmful pattern. Always review database changes — especially schema changes and data migrations — before running them in any shared environment. Rules reduce the likelihood of common mistakes; they do not eliminate the need for human judgment.

fenbs does not connect to your database or run SQL. It keeps the decisions and policies your team has approved. For database rules that depend on knowing the current schema, add the relevant table and column names to the rule text, or link to the schema documentation from the relevant decision in fenbs.

When the database schema changes significantly — new tables added, columns removed, a migration strategy updated — review your Cursor rules for references that are no longer accurate. A rule that mentions a table or column that no longer exists misleads the assistant rather than helping it. Pairing schema changes with a rule review keeps both in sync.

If the project uses multiple databases or a mix of relational and document storage, write separate rule files scoped to the code that interacts with each store. A rule about SQL query patterns should not reach code that queries a document database. The cursor rules globs article covers how to scope rules precisely to the right directories.

A rule that names which tables are the most sensitive — those that contain personal data, financial records, or audit logs — helps the assistant treat those areas with more caution. A short note such as "the users and payments tables contain personal data and are subject to stricter review" gives the assistant enough context to flag when a proposed change touches high-risk data, without embedding the full classification policy in the rule file itself. Pairing that with the destructive operations rule creates a layered approach: broad caution for all schema changes, extra caution for the tables that matter most.