feat(blog): add local-to-production with Prisma Postgres post skeleton - #8101
Conversation
Skeleton for "From Local Development to Production with Prisma Postgres": frontmatter, lead, five stubbed sections (prisma dev vs Docker locally, hosted database setup, config swap, migrations plus data import, and cutover validation), with canonical docs links in place. Prose, hero image, and meta image to follow before publishing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe new article explains how to move a Prisma application from local Docker PostgreSQL or ChangesPrisma Postgres migration guide
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
Full prose over the skeleton: five-step checklist from local Postgres (Docker or prisma dev) to hosted Prisma Postgres. Covers why prisma dev is the lighter local default with honest trade-offs, Console and CLI provisioning, the env swap, migrate deploy vs pg_dump/pg_restore paths (including the _prisma_migrations history detail), a validation pass, an FAQ, and a condensed recap checklist. Commands follow the docs; terminal outputs are illustrative. Hero and meta images still to come. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds the hero.svg and meta.png covers and completes the editorial pass on the local-to-production Prisma Postgres walkthrough. Content changes from review: - Teach the pooled/direct connection split. The draft pointed application traffic at the direct string, which silently exhausts connections under load. Adds DIRECT_URL, the prisma.config.ts datasource line, and the PgBouncer transaction-mode reasoning behind the split. - Make the environment state unambiguous. The draft told readers to swap .env and then said not to, leaving every later command's target unclear. One story now: .env points at production for the middle of the checklist, switches back at the end, with the migrate dev/reset warning and the stale-variable failure modes named in both directions. - pg_restore gains --no-owner --no-acl, matching the Neon and Supabase switch guides, instead of telling readers to ignore ownership errors. - Document the prisma dev dump path: trim Prisma's pool-tuning parameters from the printed URL, since pg_dump rejects them with "invalid URI query parameter". - Drop the prisma generate step. Connection URLs are read from the environment at runtime, not baked into the generated client. - Note the Prisma ORM 6 directUrl equivalent, the db push branch for prototypers with no migration history, the multiSchema -n caveat, and gitignoring .env before pasting production credentials. - Correct product and CLI details: version 17 client tools, positional names on prisma dev stop/rm, container runtimes beyond Docker Desktop, and the create-db 24-hour claim window. Verified against a local prisma dev instance: migrate dev applies without a separate shadow database URL, named instances get distinct ports, pg_dump with the documented flags succeeds, and _prisma_migrations travels inside the -n public dump.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@apps/blog/content/blog/from-local-to-production-with-prisma-postgres/index.mdx`:
- Around line 152-153: Update the “Starting fresh in production” guidance to add
a data-preserving path for projects created with `prisma db push`: generate and
review an initial migration using `prisma migrate diff --from-empty
--to-schema`, mark it applied on the local database with `prisma migrate resolve
--applied`, then create the dump so `_prisma_migrations` history is included
before running `migrate deploy`.
- Line 142: Update the Prisma ORM version comparison in the documented
configuration passage to state that the `directUrl` field is removed in Prisma
ORM 7, while preserving the existing explanation of `prisma.config.ts`,
`datasource.url`, and local environment variables.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 3efb5cb2-6e93-4fdc-b21a-de6e45489478
⛔ Files ignored due to path filters (2)
apps/blog/public/from-local-to-production-with-prisma-postgres/imgs/hero.svgis excluded by!**/*.svgapps/blog/public/from-local-to-production-with-prisma-postgres/imgs/meta.pngis excluded by!**/*.png
📒 Files selected for processing (1)
apps/blog/content/blog/from-local-to-production-with-prisma-postgres/index.mdx
Addresses CodeRabbit review on #8101, plus a related failure found while verifying the fix. - The db push branch told readers to run `migrate dev --name init` against their existing local database. That fails: `migrate dev` stops with P3005 ("The database schema is not empty"). Replaced with the documented baselining flow, `migrate diff --from-empty` plus `migrate resolve --applied`, which records the initial migration without touching data and gives a later dump a migration history to carry. - Drop the pg_dump instructions for local `prisma dev` instances. Dumping one crashes the local server while copying `_prisma_migrations`, so the data path now points prisma dev users at the VS Code push-to-cloud action and keeps pg_dump/pg_restore for Docker and other standard Postgres sources. - Avoid the deprecated/removed dispute on `directUrl` by stating the actionable fact: ORM 7 moves connection URLs out of the schema and into prisma.config.ts. Verified locally against prisma dev: migrate dev returns P3005 on a db push database; the baseline commands preserve rows, record 0_init, and leave migrate status reporting up to date; pg_dump succeeds with --exclude-table=_prisma_migrations and crashes the server without it.
Summary
New blog post, From Local Development to Production with Prisma Postgres, at
apps/blog/content/blog/from-local-to-production-with-prisma-postgres/index.mdx.A five-step checklist for moving a Prisma app from local Postgres (Docker or
prisma dev) to hosted Prisma Postgres: provisioning, the pooled/direct connection split, replaying migrations vs.pg_dump/pg_restore, validation, and keeping the local loop afterwards. Includes an FAQ and a condensed recap.What landed since the draft
apps/blog/public/from-local-to-production-with-prisma-postgres/imgs/(hero.svg+ pixel-identicalmeta.png, Eclipse house style, fonts embedded)..env, then said not to, leaving every later command's target unclear. Now one story, with themigrate dev/migrate resetwarning and both stale-variable failure modes named.pg_restoreuses--no-owner --no-acl, matching the Neon and Supabase switch guides.prisma devdump path: Prisma's pool-tuning URL parameters must be trimmed, sincepg_dumprejects them.prisma generatestep; connection URLs are read from the environment at runtime.directUrlequivalent, thedb pushbranch, themultiSchemacaveat, and gitignoring.env.Verification
Claims were checked against the docs source in this repo, and the CLI-dependent ones against a throwaway local
prisma devinstance:migrate devapplies without a separate shadow database URL, named instances get distinct ports,pg_dumpwith the documented flags succeeds, and_prisma_migrationstravels inside the-n publicdump. All external links return 200. Page verified as served (FAQ accordion bodies are server-rendered).Note for the author
@sorenbs the technical content changed materially under your byline, particularly the connection-string section. Worth a read before this goes out.
Summary by CodeRabbit