Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/netlify/context-and-tools/netlify-database-migration-from-extensiongit clone --depth 1 https://github.com/netlify/context-and-toolsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/netlify/context-and-tools/netlify-database-migration-from-extension)<a href="https://agentmods.dev/rules/netlify/context-and-tools/netlify-database-migration-from-extension"><img src="https://agentmods.dev/badge/rules/netlify/context-and-tools/netlify-database-migration-from-extension.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00016 | $0.02361 |
| Opus 5 | $0.00008 | $0.01180 |
| Sonnet 5 | $0.00003 | $0.00472 |
| Haiku 4.5 | $0.00002 | $0.00236 |
Grade A, and why
netlify-database-migration-from-extension scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 181 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Switching to Netlify Database
Step-by-step process for switching a project from an external Postgres provider to Netlify Database (@netlify/database, NETLIFY_DB_URL). The steps are provider-agnostic — they apply whether the source is the deprecated Netlify DB extension (@netlify/neon), a standalone Neon account, Supabase, RDS, a self-managed instance, or any other hosted Postgres.
Terminology. This document uses "switch" for the provider change and "migration" exclusively for schema migration files. The two are distinct operations that happen to overlap during this process.
Brief data-loss window. This flow trades a small data-loss risk for a much simpler cutover: any writes to the source between the final export and the production deploy will not make it across. For most projects that's a few minutes. High-traffic apps should plan a maintenance window or a dual-write strategy outside the scope of this guide.
Prerequisites
- A linked Netlify project currently serving from an existing Postgres source
- Netlify CLI 26.0.0+ installed and authenticated
pg_dumpandpg_restoreavailable locally, with versions matching your source server
The shape of the switch
Three phases, each independently reversible. The source database keeps serving production traffic until the Phase 2 merge, so any rollback before that has zero user-visible impact.
- Phase 1 — Provision the new database alongside the source. No code or traffic changes.
- Phase 2 — Swap the code and rehearse on a preview deploy with real data.
- Phase 3 — Cut over production with a fresh data move and a merge.
Phase 1 — Provision the new database
Goal: Netlify Database is online with the correct schema baseline. App still reads from the source.
Switching from the Netlify DB extension.
@netlify/databaseand@netlify/neonuse different env vars (NETLIFY_DB_URLvsNETLIFY_DATABASE_URL) and don't conflict. Keep@netlify/neoninstalled and the extension configured throughout the switch — cleanup happens at the end.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 181 lines · 16 tokens per session scan A 9fab91c3f53d
netlify-database-migration-from-extension is a cursor rule published in the GitHub repository netlify/context-and-tools (36 stars, last pushed yesterday), licensed MIT. It adds 16 tokens to every session and 2,361 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
prefer-assertions-over-defensive-checks
Prefer assertions over defensive checks when data is guaranteed to be valid.
as-contract-cast-smell
// ❌ WRONG — bypasses the family ContractSerializer seam const contract = JSON.parse(raw) as Contract; const contract = JSON.parse(raw) as Contract .
no-backward-compatibility
Do not add backward-compatibility shims or migration scaffolding.
aws-rds-best-practices
AWS RDS PostgreSQL best practices - database configuration, connection management, authentication, backup, and performance optimization standards.
database
Database rules — apply when working with database schemas, queries, migrations, or ORM models.
database
Cursor rule "database" from ItamarZand88/awesome-agent-conventions, covering database best practices, prisma setup, prisma models, prisma queries and supabase setup.