From 23b4e3db3afe20df281073b84ac504fd2b68c768 Mon Sep 17 00:00:00 2001 From: Ankur Datta <64993082+ankur-arch@users.noreply.github.com> Date: Thu, 9 Jul 2026 16:48:29 +0200 Subject: [PATCH] blog: cross-link Prisma Next posts to the /orm/next docs Add contextual documentation links across the ten Prisma Next blog posts, so readers can jump from a concept mentioned in a post to the page that covers it. Links land on the first natural mention of each concept and point at the specific doc page (contracts, fundamentals, data modeling, migrations and the migration graph, middleware, extensions, references, quickstart, and coding-agent skills). No prose was rewritten; only link syntax was added around existing words. Posts updated: the-next-evolution-of-prisma-orm, prisma-next-early-access, prisma-next-performance-benchmark, prisma-next-roadmap, prisma-next-roadmap-april-milestone, typescript-migrations-in-prisma-next, data-migrations-in-prisma-next, rethinking-database-migrations, prisma-next-call-for-extension-authors, mongodb-without-compromise. All 23 unique target URLs verified against live docs frontmatter. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../blog/data-migrations-in-prisma-next/index.mdx | 10 +++++----- .../blog/mongodb-without-compromise/index.mdx | 12 ++++++------ .../index.mdx | 10 +++++----- .../index.mdx | 10 +++++----- .../prisma-next-performance-benchmark/index.mdx | 4 ++-- .../prisma-next-roadmap-april-milestone/index.mdx | 10 +++++----- .../content/blog/prisma-next-roadmap/index.mdx | 8 ++++---- .../blog/rethinking-database-migrations/index.mdx | 10 +++++----- .../the-next-evolution-of-prisma-orm/index.mdx | 14 +++++++------- .../typescript-migrations-in-prisma-next/index.mdx | 12 ++++++------ 10 files changed, 50 insertions(+), 50 deletions(-) diff --git a/apps/blog/content/blog/data-migrations-in-prisma-next/index.mdx b/apps/blog/content/blog/data-migrations-in-prisma-next/index.mdx index 2fb7e1367c..60ba524927 100644 --- a/apps/blog/content/blog/data-migrations-in-prisma-next/index.mdx +++ b/apps/blog/content/blog/data-migrations-in-prisma-next/index.mdx @@ -17,11 +17,11 @@ series: prisma-next seriesIndex: 5 --- -Sooner or later, you need a migration to change data as well as schema. In Prisma Next, that happens inside your migration in TypeScript, with the same query builder you use in your app. +Sooner or later, you need a migration to change data as well as schema. In Prisma Next, that happens inside your migration in TypeScript, with the same [query builder](https://www.prisma.io/docs/orm/next/fundamentals/writing-data) you use in your app. -In the [previous post](https://pris.ly/ts-migrations-pn) we covered how migrations change the database schema: a TypeScript migration file with a list of operations, compiled to JSON, applied by the migration runner. Start there if any of those terms are unfamiliar. +In the [previous post](https://pris.ly/ts-migrations-pn) we covered [how migrations change the database schema](https://www.prisma.io/docs/orm/next/migrations/how-migrations-work): a TypeScript migration file with a list of operations, compiled to JSON, applied by the [migration runner](https://www.prisma.io/docs/orm/next/migrations/applying-a-migration). Start there if any of those terms are unfamiliar. -Take a common example. You've added a `displayName` column to `User` in `contract.prisma` and you want to make it `NOT NULL`. There's a snag: there are already rows in the table, and they don't have a `displayName` yet, so setting the column `NOT NULL` fails, every existing row violates the constraint. +Take a common example. You've added a `displayName` column to `User` in [`contract.prisma`](https://www.prisma.io/docs/orm/next/contract-authoring/the-data-contract) and you want to make it `NOT NULL`. There's a snag: there are already rows in the table, and they don't have a `displayName` yet, so setting the column `NOT NULL` fails, every existing row violates the constraint. A simple approach to solve this problem is to: @@ -76,7 +76,7 @@ People have asked for the obvious fix, being able to use the Prisma client _insi ## In Prisma Next, you write the data step in TypeScript -Here is the same example, written as a Prisma Next migration. The initial file is written for you by `migration plan` when you change your `contract.prisma`. The `dataTransform()` line you'd add by hand: +Here is the same example, written as a Prisma Next migration. The initial file is written for you by [`migration plan`](https://www.prisma.io/docs/orm/next/migrations/generating-a-migration) when you change your `contract.prisma`. The `dataTransform()` line you'd add by hand: ```typescript // migrations/20260422T0748_add_user_display_name/migration.ts @@ -184,7 +184,7 @@ This is what lets a data transformation reference columns the same migration is ## MongoDB gets data transformations too -Here's a `dataTransform` against a Mongo collection, backfilling a `status` field on a `products` collection so it can be made required: +Here's a `dataTransform` against a [Mongo collection](https://www.prisma.io/docs/orm/next/data-modeling/mongodb), backfilling a `status` field on a `products` collection so it can be made required: ```typescript import { dataTransform } from "@prisma-next/target-mongo/migration"; diff --git a/apps/blog/content/blog/mongodb-without-compromise/index.mdx b/apps/blog/content/blog/mongodb-without-compromise/index.mdx index 0596eec8ba..0337ff22cd 100644 --- a/apps/blog/content/blog/mongodb-without-compromise/index.mdx +++ b/apps/blog/content/blog/mongodb-without-compromise/index.mdx @@ -14,7 +14,7 @@ tags: - "announcement" --- -For the first time, Prisma Next brings the MongoDB-native experience to TypeScript. Type-safe queries, database migrations, polymorphic models, embedded collections and more. Designed in collaboration with the MongoDB DX team. +For the first time, [Prisma Next](https://www.prisma.io/docs/orm/next) brings the MongoDB-native experience to TypeScript. Type-safe queries, database migrations, polymorphic models, embedded collections and more. Designed in collaboration with the MongoDB DX team. ## What MongoDB development looks like today @@ -25,7 +25,7 @@ If you've built a MongoDB app with TypeScript recently, you've probably gone thr - You write a query and the types don't fully connect, so you cast, add guards, or accept a little `any`. - You need an index, so you drop into the MongoDB shell or a deployment script and hope your database stays in sync with your code. -In Prisma Next, you describe your data model as a contract: +In Prisma Next, you describe your [data model](https://www.prisma.io/docs/orm/next/data-modeling/mongodb) as a contract: ```prisma model User { @@ -97,13 +97,13 @@ const recentPosts = await orm.posts // recentPosts[0].author.bio -> string | null ``` -The `.include('author')` compiles to a `$lookup` pipeline stage. Skip the `.include()` and the author isn't loaded and isn't in the type. Your documents are typed all the way down, no matter how far you nest. +The [`.include('author')`](https://www.prisma.io/docs/orm/next/fundamentals/relations-and-joins) compiles to a `$lookup` pipeline stage. Skip the `.include()` and the author isn't loaded and isn't in the type. Your documents are typed all the way down, no matter how far you nest. ## Real migrations for MongoDB MongoDB is not schema-less. Your deployment has real, persistent, server-side state, and that state directly affects correctness and performance. Yet most tools do not manage it properly. -The `@@index` declarations in the contract above are not just documentation. They are managed by a migration system that versions, diffs, and deploys your database state. +The `@@index` declarations in the contract above are not just documentation. They are managed by a [migration system](https://www.prisma.io/docs/orm/next/migrations/how-migrations-work) that versions, diffs, and deploys your database state. - **Indexes:** unique, compound, TTL, partial, geospatial, text, and wildcard. If an index is wrong, queries slow down. If a unique constraint is missing, duplicate data can slip in. - **JSON Schema validators:** document-level validation rules generated from your model definitions. Even writes that bypass the ORM are still validated by the server. @@ -165,7 +165,7 @@ Polymorphism connects to migrations too. An index on a variant-specific field, ` ## Typed aggregation pipelines -When you need MongoDB's aggregation pipeline for grouping, projecting, or faceting, Prisma Next provides a typed pipeline builder: +When you need MongoDB's aggregation pipeline for grouping, projecting, or faceting, Prisma Next provides a [typed pipeline builder](https://www.prisma.io/docs/orm/next/fundamentals/advanced-queries): ```typescript const { pipeline, runtime } = orm; @@ -198,7 +198,7 @@ Field references like `f.authorId` and `f.createdAt` check against your contract })) ``` -When the pipeline builder doesn't cover what you need, you can drop to raw MongoDB commands: +When the pipeline builder doesn't cover what you need, you can drop to [raw MongoDB commands](https://www.prisma.io/docs/orm/next/reference/raw-queries): ```typescript const raw = orm.raw.collection('posts'); diff --git a/apps/blog/content/blog/prisma-next-call-for-extension-authors/index.mdx b/apps/blog/content/blog/prisma-next-call-for-extension-authors/index.mdx index 8befb897dc..30f97933f5 100644 --- a/apps/blog/content/blog/prisma-next-call-for-extension-authors/index.mdx +++ b/apps/blog/content/blog/prisma-next-call-for-extension-authors/index.mdx @@ -20,13 +20,13 @@ seriesIndex: 6 If you've ever wanted to integrate your tool, your database, or your library with Prisma, or you tried in Prisma 6 or 7 and gave up, this post is for you. Read the [Prisma Next Early Access announcement](https://www.prisma.io/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app) for the full launch story. -Prisma Next has a deliberately tiny core that knows nothing about any specific database. Postgres support is an extension. Vector search is an extension. JSON-with-schema is an extension. Whatever Prisma Next can do, it does because someone wrote it using the same components that are available to you. +[Prisma Next](https://www.prisma.io/docs/orm/next) has a deliberately tiny core that knows nothing about any specific database. Postgres support is an extension. Vector search is an extension. JSON-with-schema is an extension. Whatever Prisma Next can do, it does because someone wrote it using the same components that are available to you. The API surface is real, the same shape we used to build Postgres support ourselves, and ready to build against today. ## Postgres is an extension -The Prisma Next framework knows about contracts, plans, query lifecycle, and the policies that gate execution. It does _not_ know what Postgres, SQL, Mongo, vectors, or any column type other than `unknown` are. +The Prisma Next framework knows about [contracts](https://www.prisma.io/docs/orm/next/contract-authoring/the-data-contract), plans, query lifecycle, and the policies that gate execution. It does _not_ know what Postgres, SQL, Mongo, vectors, or any column type other than `unknown` are. Every database we support and every native feature you've used in Prisma Next was added by an extension package on a public service provider interface (SPI). The Postgres target, the SQL family (its contract shape, operations, and lanes), the Postgres adapter and driver, the pgvector vector type and its similarity operators, and the arktype-JSON codec are all extensions. @@ -34,14 +34,14 @@ There is no "core API" and "plugin API." There is one SPI, used by the team buil ## What an extension can ship -An extension is a normal npm package: `@yourname/prisma-next-extension-foo`. Your users `pnpm add` it, add one line to `prisma-next.config.ts`, and your additions show up in their contract, their queries, and (if you ship migrations) their migration plans. +An extension is a normal npm package: `@yourname/prisma-next-extension-foo`. Your users `pnpm add` it, [add one line to `prisma-next.config.ts`](https://www.prisma.io/docs/orm/next/extensions/using-extensions), and your additions show up in their contract, their queries, and (if you ship migrations) their migration plans. An extension can include any subset of four layers, in any combination: - **Contract layer**: column types, field builders, index types, and authoring constructs that show up in `contract.ts` and `contract.json` with your namespace and your validation rules. This is how pgvector adds dimensioned vector columns and how ParadeDB adds typed BM25 indexes - **Query layer**: typed methods on the query builder. Users discover them through autocomplete; they compile to SQL via lowerers you provide. This is how pgvector adds `cosineDistance` on vector columns -- **Runtime layer**: codecs that translate between the database wire format and your TypeScript types. Codecs can be synchronous (pgvector vectors decode to `number[]`) or asynchronous (encryption codecs decrypt on read with key material from an external service). Runtime middleware is also part of this slice, covering observability, audit, and policy interception around every query -- **Migration layer**: custom DDL and data operations with pre/post checks and idempotency declarations, integrated into the migration planner. ParadeDB's planned BM25 index ops land here, and so does anything else that needs to participate in the migration graph rather than ship as a one-off script +- **Runtime layer**: codecs that translate between the database wire format and your TypeScript types. Codecs can be synchronous (pgvector vectors decode to `number[]`) or asynchronous (encryption codecs decrypt on read with key material from an external service). [Runtime middleware](https://www.prisma.io/docs/orm/next/middleware/how-middleware-works) is also part of this slice, covering observability, audit, and policy interception around every query +- **Migration layer**: custom DDL and data operations with pre/post checks and idempotency declarations, integrated into the migration planner. ParadeDB's planned BM25 index ops land here, and so does anything else that needs to participate in [the migration graph](https://www.prisma.io/docs/orm/next/migrations/the-migration-graph) rather than ship as a one-off script Pick the layers you need. A useful extension can be one layer (a single codec, a single index type) or all four for a full vertical slice. diff --git a/apps/blog/content/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app/index.mdx b/apps/blog/content/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app/index.mdx index 80bdfc5672..af18326d62 100644 --- a/apps/blog/content/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app/index.mdx +++ b/apps/blog/content/blog/prisma-next-early-access-write-your-contract-prompt-your-agent-ship-your-app/index.mdx @@ -39,7 +39,7 @@ Today, **Prisma Next is open for Early Access for Postgres and [MongoDB](https:/ If you've ever picked up a new framework, you know how long it takes to climb a steep learning curve. You read the docs, build a toy project and make mistakes the docs warned you about. It takes weeks to absorb the framework's idioms until you're confident enough to actually build. -One command scaffolds a new project with Prisma Next, including a family of skills which make your agent an instant expert. +One command scaffolds a new project with Prisma Next, including a [family of skills](https://www.prisma.io/docs/ai/tools/skills) which make your agent an instant expert. ```bash npm create prisma@next @@ -61,7 +61,7 @@ model Book { } ``` -This is the contract between your application and your database. The models are what your application depends on, and your database promises to store them in the shapes described in the contract. +This is [the contract](https://www.prisma.io/docs/orm/next/contract-authoring/the-data-contract) between your application and your database. The models are what your application depends on, and your database promises to store them in the shapes described in the contract. It's easy to read, easy to update, and it's the single source of truth for everything in Prisma Next. Queries are type-checked against it, autocomplete reads from it, and when you change it, Prisma Next plans the migrations to match, so your database continues to satisfy the contract. @@ -84,7 +84,7 @@ Considering the book table in the contract above, you can ask the agent for a fe after={contractAfterAuthor} /> -Then, when you ask the agent to write a query, it iterates inside its own tool calls until the query type-checks, or until it resolves any errors. Here's what that looks like in practice: +Then, when you ask the agent to [write a query](https://www.prisma.io/docs/orm/next/fundamentals/reading-data), it iterates inside its own tool calls until the query type-checks, or until it resolves any errors. Here's what that looks like in practice: