Best Cursor Rules for PostgreSQL
Cursor RulesDifficulty: IntermediateUpdated: 2026-05-25
Rules to design tables, migrations, and queries safely with Postgres.
Use this rule if you are building:
- Real-world feature work with minimal diffs
- Keeping edits scoped to the requested files
This rule helps Cursor avoid:
- Modifying unrelated files
- Leaking env values
- Breaking API routes and request boundaries
- Editing database migrations without review
Copy Cursor Rules
Paste into .cursorrules at your repo root.
# Project: Best Cursor Rules for PostgreSQL
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.Show full rules
# Project: Best Cursor Rules for PostgreSQL
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.What this Cursor rule is for
Keep edits scoped, protect critical files, and enforce safe patterns for PostgreSQL / SQL / Migrations projects.
Who should use it
- Indie developers shipping production features fast
- Teams that want predictable AI changes with minimal diff
Copy the Cursor rule
# Project: Best Cursor Rules for PostgreSQL
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.
Recommended project structure
- src/app
- src/components
- src/lib
- content/cursor-rules
How to use it in Cursor
- Copy the block into your repo root as
.cursorrules - Restart Cursor
- Test by asking it to change one small file
Common mistakes
- Rules exist but Cursor uses a different workspace root
- Rules are too vague and not actionable
Related workflows
- Use Cursor to Fix Vercel Build Errors
- Build SEO Landing Pages with Cursor
Related MCP servers
- Best MCP Servers for Cursor
- Best File System MCP Servers
FAQ
Should I allow the agent to edit database migrations automatically?
Prefer manual review for any schema change and run migrations locally first.