Zero-config Postgres for Netlify apps via @netlify/database — querying data from Functions/Edge Functions, writing schema migrations, setting up Drizzle ORM, local dev with netlify dev, database branches for deploy previews, and migrating an existing Postgres project onto Netlify. Use when adding a database, building a contact form or CRUD API, writing SQL migrations, wiring up Drizzle, running netlify database commands, testing with a local Postgres, or switching from Neon/Supabase/RDS to Netli
This skill teaches an agent how to add and use Netlify's zero-config managed Postgres (`@netlify/database`) in a Netlify application. It solves the problem of provisioning, connecting to, and evolving a database without manual infrastructure work: you install the package, write SQL migration files under `netlify/database/migrations/`, and on deploy Netlify provisions the database and applies migrations automatically. The database is queryable from Functions, Edge Functions, Builds, and Agent Runners.
The reference covers the modern client (`getDatabase()` with auto-parameterized tagged-template `sql` queries, streaming and chunked reads, typed rows, and `toSQL()`), raw connection strings via `getConnectionString()`, transaction handling on `db.pool` (a `pg.Pool`), and integration with the Drizzle ORM through the `drizzle-orm/netlify-db` adapter (which must be installed from `@beta`). Supporting documents describe the Netlify CLI database commands, local development with `netlify dev`, deploy-preview database branches, migration workflows, operational footguns, and a phased, rehearsable guide for switching an existing Postgres project (Neon, Supabase, RDS, or the deprecated `@netlify/neon` extension) onto Netlify Database using `pg_dump`/`pg_restore`.
It targets full-stack and frontend developers building on Netlify who need a database for a contact form, CRUD API, or similar app, as well as teams migrating off another Postgres provider. The guidance is security-conscious: it emphasizes automatic query parameterization and explicitly warns that `sql.raw` and `sql.unsafe` bypass injection protection and must only receive trusted constants, never user input.
Call `getDatabase()` to get a client, then use its tagged-template `sql` method (e.g. `db.sql`SELECT * FROM users WHERE id = ${id}``), which auto-parameterizes interpolated values. For transactions, use `db.pool` (a pg.Pool) so BEGIN/COMMIT run on the same connection.
No. It is zero-config: installing `@netlify/database` and deploying causes Netlify to provision the DB and apply your migrations. The connection is auto-selected per runtime via `getDatabase()`, or you can get the correct branch string with `getConnectionString()` / the `NETLIFY_DB_URL` env var.
Yes, via the `drizzle-orm/netlify-db` adapter, but both `@netlify/database` and `drizzle-orm` must be installed from `@beta` — the `latest` tag lacks the adapter and will fail.
No. `@netlify/neon` and the `NETLIFY_DATABASE_URL` env var are deprecated and superseded by `@netlify/database` and `NETLIFY_DB_URL`. New code should not use `neon()` calls.
The migration reference describes a three-phase, provider-agnostic flow: provision the new DB with a schema-only baseline migration, swap application code and rehearse on a preview deploy with real data copied via pg_dump/pg_restore, then cut over production. It notes a brief data-loss window for writes between the final export and the production deploy.
Quick Setup:
.claude/skills/Repository
netlify/context-and-tools