Add PlanetScale Postgres documentation #7433
Conversation
- Add new PlanetScale Postgres database guide with connection pooling, branching, and replica information - Add PlanetScale Postgres quickstart guide - Add PlanetScale Postgres add-to-existing-project guide - Rename existing PlanetScale pages to 'PlanetScale MySQL' for clarity - Update sidebar with new PlanetScale Postgres entries - Fix 'Planetscale' -> 'PlanetScale' case sensitivity issues
WalkthroughThis PR introduces comprehensive documentation for PlanetScale Postgres while disambiguating existing PlanetScale documentation as "PlanetScale MySQL". It adds four new quickstart and integration guides, updates sidebar navigation, corrects capitalization inconsistencies, and establishes cross-references between MySQL and Postgres variants. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes The PR spans multiple documentation files with substantive new content (~720 lines across new guides), but follows consistent structural patterns. Review effort centers on verifying technical accuracy, link validity, code example correctness, and consistency across the MySQL/Postgres documentation pairs rather than logic complexity. Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
content/200-orm/050-overview/500-databases/855-planetscale-postgres.mdx (1)
114-120: Consider using template literal pattern for connection string consistency.Based on learnings from similar documentation, the Prisma docs convention for driver adapter examples uses the template literal pattern for environment variable access:
-const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL }) +const connectionString = `${process.env.DATABASE_URL}` +const adapter = new PrismaPg({ connectionString })This maintains consistency with other database adapter examples (PostgreSQL, MySQL/MariaDB) throughout the documentation.
content/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdx (1)
105-107: Consider using a placeholder for the database name.The connection string uses
postgresas a hardcoded database name while other values use placeholder syntax. For consistency and to avoid confusion, consider using a placeholder:-DATABASE_URL="postgresql://{username}:{password}@{host}:6432/postgres?sslmode=verify-full" +DATABASE_URL="postgresql://{username}:{password}@{host}:6432/{database}?sslmode=verify-full"This helps users understand they should replace this with their actual database name from PlanetScale.
content/100-getting-started/02-prisma-orm/200-add-to-existing-project/600-planetscale.mdx (1)
130-140: Consider using the template literal pattern for connection string consistency.Based on learnings, the Prisma docs convention for driver adapter examples uses the template literal pattern for environment variables. The current code passes
process.env.DATABASE_URLdirectly to the adapter options object. While functionally equivalent, using the template literal maintains consistency across all database adapter examples in the documentation.📝 Suggested change for consistency
import "dotenv/config"; import { PrismaPlanetScale } from '@prisma/adapter-planetscale' import { PrismaClient } from '../generated/prisma/client' import { fetch as undiciFetch } from 'undici' -const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL, fetch: undiciFetch }) +const connectionString = `${process.env.DATABASE_URL}` + +const adapter = new PrismaPlanetScale({ url: connectionString, fetch: undiciFetch }) const prisma = new PrismaClient({ adapter }) export { prisma }content/100-getting-started/02-prisma-orm/100-quickstart/605-planetscale-postgres.mdx (2)
53-68: Consider adding a brief explanation forignoreDeprecations.The
ignoreDeprecations: "6.0"setting in tsconfig may puzzle readers unfamiliar with TypeScript 5.x deprecation warnings formoduleResolution: "node". A short inline comment or note explaining why this is needed would help developers understand this isn't a red flag.
199-214: Clarify thatmigrate devalready runsgenerateautomatically.The current text shows running
prisma migrate dev(Line 204) followed by a separateprisma generate(Line 212). Since Prisma 3.x+,migrate devautomatically runsgenerateafter successful migration. Running it again is harmless but redundant. You could either remove the explicit generate step or clarify it's optional/for emphasis.📝 Suggested clarification
This command creates the database tables based on your schema. -Now run the following command to generate the Prisma Client: +The `migrate dev` command automatically generates Prisma Client after applying migrations. If you need to regenerate manually (e.g., after schema changes without migration), run: ```terminal npx prisma generate</details> </blockquote></details> <details> <summary>content/100-getting-started/02-prisma-orm/100-quickstart/600-planetscale.mdx (1)</summary><blockquote> `212-222`: **Same template literal pattern note as the add-to-existing guide.** For consistency with other database adapter examples in the Prisma docs (and with the new Postgres quickstart in this PR which does use the pattern), consider using the template literal approach here as well. Based on learnings, the convention is `const connectionString = \`${process.env.DATABASE_URL}\``. <details> <summary>📝 Suggested change for consistency</summary> ```diff import "dotenv/config"; import { PrismaPlanetScale } from '@prisma/adapter-planetscale' import { PrismaClient } from '../generated/prisma/client' import { fetch as undiciFetch } from 'undici' -const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL, fetch: undiciFetch }) +const connectionString = `${process.env.DATABASE_URL}` + +const adapter = new PrismaPlanetScale({ url: connectionString, fetch: undiciFetch }) const prisma = new PrismaClient({ adapter }) export { prisma }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
content/100-getting-started/02-prisma-orm/100-quickstart/600-planetscale.mdxcontent/100-getting-started/02-prisma-orm/100-quickstart/605-planetscale-postgres.mdxcontent/100-getting-started/02-prisma-orm/200-add-to-existing-project/600-planetscale.mdxcontent/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdxcontent/200-orm/050-overview/500-databases/850-planetscale.mdxcontent/200-orm/050-overview/500-databases/855-planetscale-postgres.mdxcontent/300-accelerate/900-compare.mdxsidebars.tssrc/data/indexData.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-01-06T22:06:57.725Z
Learnt from: newclarityex
Repo: prisma/docs PR: 7425
File: content/200-orm/050-overview/500-databases/400-mysql.mdx:80-80
Timestamp: 2026-01-06T22:06:57.725Z
Learning: In Prisma docs, when showing examples of instantiating driver adapters with connection strings from environment variables, use the template literal pattern `const connectionString = `${process.env.DATABASE_URL}`` for consistency across all database adapter examples (PostgreSQL, MySQL/MariaDB, etc.).
Applied to files:
content/200-orm/050-overview/500-databases/855-planetscale-postgres.mdxcontent/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdxcontent/100-getting-started/02-prisma-orm/200-add-to-existing-project/600-planetscale.mdxcontent/100-getting-started/02-prisma-orm/100-quickstart/605-planetscale-postgres.mdxcontent/300-accelerate/900-compare.mdxcontent/200-orm/050-overview/500-databases/850-planetscale.mdxcontent/100-getting-started/02-prisma-orm/100-quickstart/600-planetscale.mdx
🪛 LanguageTool
content/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdx
[style] ~228-~228: Consider shortening or rephrasing this to strengthen your wording.
Context: ...pt.ts ``` ## 9. Evolve your schema To make changes to your database schema: ### 9.1. Update ...
(MAKE_CHANGES)
🔇 Additional comments (14)
content/300-accelerate/900-compare.mdx (1)
31-31: Capitalization corrections look good.These changes properly align the "PlanetScale" brand name with the correct casing throughout the comparison tables. Consistent branding across documentation is important for professionalism and searchability.
Also applies to: 102-102
content/200-orm/050-overview/500-databases/855-planetscale-postgres.mdx (1)
1-141: Well-structured documentation for PlanetScale Postgres.This is a solid addition to the Prisma docs. The document effectively:
- Distinguishes between PlanetScale Postgres and MySQL variants with clear cross-references
- Explains the PostgreSQL-compatible nature and standard
postgresqlprovider usage- Documents the dual connection approach (direct vs PgBouncer) with a helpful comparison table
- Provides complete code examples for schema and client setup
The note block at lines 13-17 is particularly helpful for users who may land on the wrong guide.
content/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdx (2)
182-193: Good adherence to documentation conventions.The Prisma Client instantiation correctly uses the template literal pattern for the connection string as per documentation standards:
const connectionString = `${process.env.DATABASE_URL}`This maintains consistency with other database adapter examples across the Prisma docs.
1-279: Comprehensive add-to-existing-project guide.This guide provides excellent step-by-step coverage for integrating Prisma ORM with an existing PlanetScale Postgres project. The workflow is logical:
- Set up dependencies
- Initialize Prisma
- Connect database
- Introspect existing schema
- Baseline for migrations
- Generate client and query
The baselining section (lines 142-166) is particularly valuable for users migrating existing databases, as this is often a point of confusion.
content/200-orm/050-overview/500-databases/850-planetscale.mdx (1)
2-15: Clear disambiguation between PlanetScale MySQL and Postgres.The title change to "PlanetScale MySQL" and the added note block effectively distinguish this guide from the new PlanetScale Postgres documentation. This is the right approach—users searching for PlanetScale guidance will now clearly understand which guide applies to their database variant.
The note at lines 11-15 provides a helpful redirect for users who may have landed here while using PlanetScale Postgres.
src/data/indexData.ts (1)
179-179: Brand name capitalization corrected.The
techlabel now correctly displays "PlanetScale" with proper casing. This ensures the UI matches the updated documentation and official brand spelling.content/100-getting-started/02-prisma-orm/200-add-to-existing-project/600-planetscale.mdx (1)
2-3: LGTM on the title and cross-reference updates.The renaming to "PlanetScale MySQL" and the updated note correctly directing users to the new PlanetScale Postgres guide are well done. This establishes clear disambiguation between the two PlanetScale offerings.
Also applies to: 16-17
content/100-getting-started/02-prisma-orm/100-quickstart/605-planetscale-postgres.mdx (3)
1-19: Well-structured frontmatter and introduction.The metadata is complete, and the cross-reference note to the MySQL guide mirrors the pattern used in the MySQL guide pointing back here. This bidirectional linking helps users find the right documentation.
219-230: LGTM on Prisma Client instantiation.The code correctly uses the
@prisma/adapter-pgwithPrismaPg, and follows the template literal pattern for the connection string as per documentation conventions.
130-148: Helpful connection type table.The table clearly distinguishing Direct (5432) vs PgBouncer (6432) ports with their use cases is excellent. This prevents a common pitfall where developers use pooled connections for migrations, which can cause issues.
sidebars.ts (3)
107-115: LGTM on quickstart sidebar updates.The existing PlanetScale entry is correctly relabeled to "PlanetScale MySQL" and the new "PlanetScale Postgres" entry follows with the correct doc ID. The ordering (MySQL before Postgres) maintains backward compatibility for existing users.
168-176: LGTM on add-to-existing-project sidebar updates.Mirrors the quickstart pattern correctly, maintaining consistency across both getting-started paths.
510-510: Formatting-only change, no semantic impact.The AI tutorials items array was reformatted to a single line. No functional change.
content/100-getting-started/02-prisma-orm/100-quickstart/600-planetscale.mdx (1)
2-3: LGTM on MySQL quickstart title and cross-reference.The renaming to "PlanetScale MySQL" and the note pointing to the Postgres quickstart are correct. The bidirectional linking between MySQL and Postgres guides creates a good user experience.
Also applies to: 17-17
1 participant
Summary
PlanetScale offers PostgreSQL databases in addition to our MySQL (Vitess) offering.
Changes
New pages:
content/200-orm/050-overview/500-databases/855-planetscale-postgres.mdx)content/100-getting-started/02-prisma-orm/100-quickstart/605-planetscale-postgres.mdx)content/100-getting-started/02-prisma-orm/200-add-to-existing-project/605-planetscale-postgres.mdx)Updated pages:
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.