@prisma/orm-sqlite 8.0.0-rc.9-dev.8 → 8.0.0-rc.9-dev.10

package/skills/prisma-8/references/queries-mongo.md

@@ -9,7 +9,7 @@ Shared concepts (result consumption, script teardown, cross-target pitfalls, cap
 **Mongo** (`mongo<Contract>(...)` from `@internal/mongo/runtime`):
 
 - **`db.orm.<root>`** — ORM, lowercased plural contract root (`db.orm.users`, `db.orm.posts`). Same fluent chaining; `.where({ field: value })` object equality is the idiomatic filter form.
-- **`db.query`** — typed aggregation-pipeline builder. Start with `db.query.from('<root>')`, chain `.match(...)` / `.project(...)` / `.group(...)` / `.lookup(...)`, terminal with `.build()`. Execute via `(await db.runtime()).execute(plan)`.
+- **`db.query`** — typed aggregation-pipeline builder. Start with `db.query.from('<root>')`, chain `.match(...)` / `.project(...)` / `.group(...)` / `.lookup(...)`, terminal with `.build()`. Run via `(await db.runtime()).query(plan)` for anything that returns documents; `execute(plan)` is only for a write you want an affected count from, and it throws `RUNTIME.MONGO_STATISTICS_UNSUPPORTED` on a find or aggregate.
 
 Reach for the ORM first; drop to `db.query` when the ORM can't express the shape. Lane choice is local — one query function picks one lane, not the whole app.
 
@@ -49,7 +49,7 @@ const recent = await db.orm.posts
 
 **`.where(...)`** accepts a plain object whose keys are model field names and values are compared with equality (codec-aware — `ObjectId` fields accept string ids from the contract). Chain multiple `.where({ ... })` calls to AND-compose filters.
 
-For operators the object form doesn't cover (`.in([...])`, range comparisons, nested logic), pass a `MongoFilterExpr` — today that means importing filter helpers from `@internal/mongo-query-ast/execution` (a façade-completeness gap; see *What Prisma 8 doesn't do yet* in [`queries.md`](./queries.md)). Prefer the object form whenever equality suffices.
+For operators the object form doesn't cover (`.in([...])`, range comparisons, nested logic), pass a `MongoFilterExpr` — today that means importing filter helpers from `@prisma/orm-mongo/query-ast/execution` (a façade-completeness gap; see *What Prisma 8 doesn't do yet* in [`queries.md`](./queries.md)). Prefer the object form whenever equality suffices.
 
 **Polymorphic roots.** When the contract declares variants on a model, narrow before querying:
 
@@ -123,7 +123,7 @@ await db.orm.users.where({ email: 'alice@example.com' }).upsert({
 The Mongo ORM does not expose `.aggregate(...)` / `.groupBy(...)`. Express aggregations through **`db.query`** — the pipeline builder — with `.group(...)` and accumulator helpers:
 
 ```typescript
-import { acc } from '@internal/mongo-query-builder';
+import { acc } from '@prisma/orm-mongo/query-builder';
 
 const runtime = await db.runtime();
 const plan = db.query
@@ -137,18 +137,18 @@ const plan = db.query
   .sort({ postCount: -1 })
   .build();
 
-const byKind = await runtime.execute(plan);
+const byKind = await runtime.query(plan);
 ```
 
-Import `acc` and expression helpers (`fn`) from `@internal/mongo-query-builder` when building computed pipeline stages.
+Import `acc` and expression helpers (`fn`) from `@prisma/orm-mongo/query-builder` when building computed pipeline stages (as `examples/mongo-demo/src/server.ts` does).
 
 ## Workflow — Query builder (`db.query`)
 
-The concept: `db.query.from('<root>')` starts a typed aggregation-pipeline chain. Terminal methods produce a `MongoQueryPlan`; execute it through the runtime:
+The concept: `db.query.from('<root>')` starts a typed aggregation-pipeline chain. Terminal methods produce a `MongoQueryPlan`; run it through the runtime with `query(plan)` (an `AsyncIterableResult` of documents — `await` it for an array):
 
 ```typescript
 // src/queries/analytics.ts
-import { acc, fn } from '@internal/mongo-query-builder';
+import { acc, fn } from '@prisma/orm-mongo/query-builder';
 import { db } from '../prisma/db';
 
 const runtime = await db.runtime();
@@ -161,7 +161,7 @@ const plan = db.query
   .limit(10)
   .project('title', 'authorId', 'createdAt')
   .build();
-const recent = await runtime.execute(plan);
+const recent = await runtime.query(plan);
 
 // Cross-collection join ($lookup).
 const withAuthor = db.query
@@ -175,26 +175,26 @@ const withAuthor = db.query
       .as('author'),
   )
   .build();
-const rows = await runtime.execute(withAuthor);
+const rows = await runtime.query(withAuthor);
 ```
 
 **Filters — `.match(...)`.** Callback form: `.match((f) => f.status.eq('active'))`. Filters AND-compose across chained `.match(...)` calls. Field accessors support property access (`f.email`), callable dot paths (`f('address.city').eq('NYC')`), and `f.rawPath('path')` for migration/backfill paths outside the current contract.
 
-**Write terminals on the builder.** After `.from('users')` or `.from('users').match(...)`, use insert/update/delete terminals:
+**Write terminals on the builder.** After `.from('users')` or `.from('users').match(...)`, use insert/update/delete terminals. Write plans run through `query(plan)` too (one result row carrying the driver's response — the inserted ids, or the document `findOneAndUpdate` returns); reach for `execute(plan)` only on an `update*` / `delete*` plan when all you want is the affected count (any other command kind throws `RUNTIME.MONGO_STATISTICS_UNSUPPORTED`):
 
 ```typescript
-await runtime.execute(
+const inserted = await runtime.query(
   db.query.from('users').insertOne({ name: 'Alice', email: 'a@e.com', bio: null }),
 );
 
-await runtime.execute(
+const { affectedRows } = await runtime.execute(
   db.query
     .from('users')
     .match((f) => f.name.eq('Alice'))
     .updateMany((f) => [f.bio.set('filled')]),
 );
 
-await runtime.execute(
+const [updated] = await runtime.query(
   db.query
     .from('users')
     .match((f) => f.email.eq('a@e.com'))
@@ -204,7 +204,7 @@ await runtime.execute(
 
 Update callbacks return arrays of field operations (`.set`, `.inc`, `.push`, `.pull`, …). Pipeline-style updates use `f.stage.set(...)` inside an aggregation chain, then `.updateMany()` with no callback.
 
-**Plans vs ORM.** The ORM's `.create` / `.update` / `.all` issue queries directly. Don't pass ORM collections to `runtime.execute` — that entry point is for `db.query` plans (and migration/runtime internals).
+**Plans vs ORM.** The ORM's `.create` / `.update` / `.all` issue queries directly. Don't pass ORM collections to `runtime.query` / `runtime.execute` — those entry points are for `db.query` plans (and migration/runtime internals).
 
 ## Common Pitfalls (Mongo)
 
@@ -215,7 +215,7 @@ Update callbacks return arrays of field operations (`.set`, `.inc`, `.push`, `.p
 5. **Expecting Postgres-style lambda `.where((u) => u.email.eq(...))` on ORM.** Prefer object equality `.where({ email: '...' })`; richer operators need `MongoFilterExpr` helpers (façade gap today).
 6. **Expecting `db.transaction(...)`.** The Mongo façade does not expose it today. Multi-document atomicity requires MongoDB transactions on a replica set via the driver — not yet wrapped in the Prisma 8 façade. Route to *What Prisma 8 doesn't do yet* / `references/feedback.md` if the user needs this.
 7. **Trying to use `db.sql`.** There is no `db.sql` on Mongo.
-8. **Trying to `db.execute(plan)` directly.** Execute query-builder plans via `(await db.runtime()).execute(plan)`.
+8. **Trying to `db.execute(plan)` directly, or reading documents with `execute`.** Run query-builder plans via `(await db.runtime()).query(plan)`. `execute(plan)` resolves statistics only and throws `RUNTIME.MONGO_STATISTICS_UNSUPPORTED` for a find or aggregate.
 9. **Expecting ORM `.aggregate(...)` / `.groupBy(...)`.** Use `db.query.from(...).group(...).build()` instead.
 
 ## Reference Files
@@ -230,7 +230,7 @@ Update callbacks return arrays of field operations (`.set`, `.inc`, `.push`, `.p
 - [ ] Used lowercased plural ORM roots (`db.orm.users`, not `db.orm.User`).
 - [ ] Chose the right lane (ORM by default; `db.query` for shapes the ORM doesn't express).
 - [ ] Used `.where({ ... }).first()` for single-row reads — not `.all()`.
-- [ ] Executed query-builder plans via `(await db.runtime()).execute(plan)`.
+- [ ] Ran query-builder plans via `(await db.runtime()).query(plan)`; used `execute(plan)` only for an affected count on a write.
 - [ ] For aggregations, used `db.query.from(...).group(...)` rather than a non-existent ORM `.aggregate(...)`.
 - [ ] Did NOT confabulate `db.transaction`, `db.sql`, or ORM `.aggregate(...)` — routed to *What Prisma 8 doesn't do yet* / `references/feedback.md` instead.
 - [ ] Did NOT use the lower-level builder for something the ORM cleanly expresses.

package/skills/prisma-8/references/queries-postgres.md

@@ -8,8 +8,8 @@ Shared concepts (result consumption, script teardown, cross-target pitfalls, cap
 
 **Postgres** (`postgres<Contract>(...)` from `@internal/postgres/runtime`):
 
-- **`db.orm.<Model>`** — ORM, PascalCase model name (`db.orm.User`). Fluent `.where(...).select(...).orderBy(...).all()`, fully typed against `Contract`. Default lane for CRUD with relations.
-- **`db.sql.<table>`** — SQL builder, lowercase storage name (`db.sql.user`). Produces a *plan* executed via `db.runtime().execute(plan)`. Use when the ORM is too high-level — explicit `JOIN`, computed projections, set operations, window functions.
+- **`db.orm.<ns>.<Model>`** — ORM, PascalCase model name (`db.orm.public.User`). Fluent `.where(...).select(...).orderBy(...).all()`, fully typed against `Contract`. Default lane for CRUD with relations.
+- **`db.sql.<ns>.<table>`** — SQL builder, lowercase storage name (`db.sql.public.user`). Produces a *plan*. A plan that returns rows (`select`, or a write with `.returning(...)`) runs through `db.runtime().query(plan)`; a write with no `RETURNING` runs through `db.runtime().execute(plan)`, which resolves `{ affectedRows }`. Use when the ORM is too high-level — explicit `JOIN`, computed projections, set operations, window functions.
 
 Reach for the ORM first; drop to `db.sql` when the ORM can't express the shape. Lane choice is local — one query function picks one lane, not the whole app.
 
@@ -17,33 +17,33 @@ Reach for the ORM first; drop to `db.sql` when the ORM can't express the shape.
 
 | Need | Choose | Why |
 | --- | --- | --- |
-| Standard CRUD with relations | **ORM (`db.orm.<Model>`)** | Highest ergonomics; fully typed; model-shaped. |
+| Standard CRUD with relations | **ORM (`db.orm.<ns>.<Model>`)** | Highest ergonomics; fully typed; model-shaped. |
 | Eager-load related records | **ORM `.include(...)`** | Composes with `.where` / `.select` / `.orderBy` / `.limit` per branch. |
 | Aggregate (count, sum, avg) | **ORM `.aggregate(...)`** | Typed result; works with grouping (`.groupBy(...).aggregate(...)`). |
-| `INSERT ... RETURNING` / `UPDATE ... RETURNING` typed result | **ORM mutations** (returns updated rows) or **`db.sql.<t>.insert(...).returning(...)`** | ORM returns inserted/updated rows; SQL builder exposes `.returning(...)` explicitly. |
-| Computed projection (e.g. `ST_DistanceSphere(location, point) AS meters`) alongside model fields | **SQL builder (`db.sql.<t>`)** | The ORM projects model fields; arbitrary expression projection is the SQL builder's seam. |
+| `INSERT ... RETURNING` / `UPDATE ... RETURNING` typed result | **ORM mutations** (returns updated rows) or **`db.sql.<ns>.<t>.insert(...).returning(...)`** | ORM returns inserted/updated rows; SQL builder exposes `.returning(...)` explicitly. |
+| Computed projection (e.g. `ST_DistanceSphere(location, point) AS meters`) alongside model fields | **SQL builder (`db.sql.<ns>.<t>`)** | The ORM projects model fields; arbitrary expression projection is the SQL builder's seam. |
 | Complex `JOIN`, set operation, window function | **SQL builder** | The ORM doesn't express arbitrary joins. |
-| Postgres-specific feature (`LATERAL`, `FILTER`, custom aggregates) | **SQL builder**, falling back to extension operators when the extension provides them | DSL first; extensions can contribute operators (`postgis`, `pgvector`, `cipherstash`). |
+| Postgres-specific feature (`LATERAL`, `FILTER`, custom aggregates) | **SQL builder**, falling back to extension operators when the extension provides them | DSL first; extensions can contribute operators (`postgis`, `pgvector`). |
 
 ## Workflow — ORM reads
 
-The concept: `db.orm.<Model>` returns a *collection* you compose method-by-method. Each call returns a new collection (immutable chaining); the terminal verb (`.all()` / `.first()` / `.count()` / `.aggregate(...)`) issues the query. Predicates are lambdas over a field proxy: `u.field.<op>(value)`.
+The concept: `db.orm.<ns>.<Model>` returns a *collection* you compose method-by-method. Each call returns a new collection (immutable chaining); the terminal verb (`.all()` / `.first()` / `.aggregate(...)`) issues the query. There is no `.count()` terminal on the collection — `count()` is an `include` reducer and an `aggregate(...)` operation (both below). Predicates are lambdas over a field proxy: `u.field.<op>(value)`.
 
 ```typescript
 // src/queries/users.ts — one directory deep under src/, so the import is '../prisma/db'
 import { db } from '../prisma/db';
 
 // Find one record by primary key shorthand.
-const user = await db.orm.User.first({ id: userId });
+const user = await db.orm.public.User.first({ id: userId });
 // Returns the full row or `null`.
 
 // Find one matching a predicate.
-const alice = await db.orm.User
+const alice = await db.orm.public.User
   .where((u) => u.email.eq('alice@example.com'))
   .first();
 
 // Find many with projection, sort, and limit.
-const recentUsers = await db.orm.User
+const recentUsers = await db.orm.public.User
   .select('id', 'email', 'createdAt')
   .orderBy((u) => u.createdAt.desc())
   .limit(10)
@@ -54,38 +54,38 @@ const recentUsers = await db.orm.User
 
 ```typescript
 // Lambda form — full expression power.
-db.orm.User.where((u) => u.email.eq('alice@example.com'));
+db.orm.public.User.where((u) => u.email.eq('alice@example.com'));
 
 // Shorthand object form — equality on the named fields.
-db.orm.User.where({ kind: 'admin' });
+db.orm.public.User.where({ kind: 'admin' });
 ```
 
-Operators on the field proxy include `.eq`, `.neq`, `.lt`, `.lte`, `.gt`, `.gte`, `.like`, `.ilike`, `.in([...])`, `.isNull()`, `.isNotNull()`. Extensions add target-specific operators on extension-typed columns (`pgvector`'s `.cosineDistance(...)`, `postgis`'s `.within(...)` / `.intersectsBbox(...)` / `.distanceSphere(...)`, `cipherstash`'s `.cipherstashEq(...)` / `.cipherstashGt(...)` / …).
+Operators on the field proxy include `.eq`, `.neq`, `.lt`, `.lte`, `.gt`, `.gte`, `.like`, `.ilike`, `.in([...])`, `.isNull()`, `.isNotNull()`. Extensions add target-specific operators on extension-typed columns (`pgvector`'s `.cosineDistance(...)`, `postgis`'s `.within(...)` / `.intersectsBbox(...)` / `.distanceSphere(...)`).
 
 **There is no `.between(a, b)` operator.** Express ranges either as two chained `.where(...)` clauses (the idiomatic form — clauses AND-compose) or with the `and(...)` combinator inside one clause:
 
 ```typescript
 // Chained .where() — each clause AND-composes with the previous one.
-await db.orm.Sale
+await db.orm.public.Sale
   .where((s) => s.day.gte(start))
   .where((s) => s.day.lte(end))
   .all();
 
 // Equivalent with an explicit `and(...)` inside one clause.
-import { and } from '@internal/sql-orm-client'; // façade re-export pending — see *What PN doesn't do yet* in queries.md
-await db.orm.Sale
+import { and } from '@prisma/orm-postgres/orm-client';
+await db.orm.public.Sale
   .where((s) => and(s.day.gte(start), s.day.lte(end)))
   .all();
 ```
 
 The two forms emit the same SQL. Pick chained `.where()` when each clause adds a separate condition that reads as its own thought; pick `and(...)` when one logical predicate happens to have two parts and you want the visual grouping. Don't reach for a `between` helper — there isn't one.
 
-**Combinators** (`and`, `or`, `not`) compose predicates, and **relation predicates** (`.some(...)`, `.none(...)`, `.every(...)`) recurse into a relation. These currently come from the internal `@internal/sql-orm-client` package — see *What Prisma 8 doesn't do yet* in [`queries.md`](./queries.md):
+**Combinators** (`and`, `or`, `not`) compose predicates, and **relation predicates** (`.some(...)`, `.none(...)`, `.every(...)`) recurse into a relation. The combinators are exported from the façade's `orm-client` subpath:
 
 ```typescript
-import { and, or, not } from '@internal/sql-orm-client';
+import { and, or, not } from '@prisma/orm-postgres/orm-client';
 
-await db.orm.User
+await db.orm.public.User
   .where((u) =>
     and(
       or(u.kind.eq('admin'), u.email.ilike('%@example.com')),
@@ -98,7 +98,7 @@ await db.orm.User
 **Sorting and pagination.** `.orderBy(...)` accepts a single lambda or an array of lambdas (each calling `.asc()` / `.desc()` on a field). `.limit(n)` limits; `.offset(n)` offsets.
 
 ```typescript
-await db.orm.Post
+await db.orm.public.Post
   .where((p) => p.authorId.eq(userId))
   .orderBy([(p) => p.createdAt.desc(), (p) => p.id.desc()])
   .limit(20)
@@ -108,13 +108,13 @@ await db.orm.Post
 **Cursor pagination.** Call `.cursor({ field: lastValue })` after `.orderBy(...)` to resume from a known position. The cursor requires a prior `orderBy` — the type system enforces this. Direction (forward or backward) follows the sort: ascending order means "greater than the cursor value", descending means "less than".
 
 ```typescript
-const page1 = await db.orm.Post
+const page1 = await db.orm.public.Post
   .orderBy((p) => p.createdAt.desc())
   .limit(20)
   .all();
 
 const last = page1[page1.length - 1]!;
-const page2 = await db.orm.Post
+const page2 = await db.orm.public.Post
   .orderBy((p) => p.createdAt.desc())
   .cursor({ createdAt: last.createdAt })
   .limit(20)
@@ -130,7 +130,7 @@ Cursor keys must match fields in the active `orderBy`. For a composite `orderBy`
 The concept: `.include('<relation>', (branch) => branch.<chain>)` adds a relation branch to the parent query. The branch is its own collection — compose `.where` / `.select` / `.orderBy` / `.limit` on it just like the parent.
 
 ```typescript
-await db.orm.User
+await db.orm.public.User
   .select('id', 'email')
   .include('posts', (post) =>
     post
@@ -146,25 +146,25 @@ await db.orm.User
 **Reduce a to-many relation to a scalar.** A refinement callback may return a *reducer* — `count()`, `sum(field)`, `avg(field)`, `min(field)`, `max(field)`, plus the lossless `countBigInt()`, `sumBigInt(field)`, and `avgDecimal(field)` — instead of a collection. The parent's relation field then carries that one value rather than an array. Reducers exist only inside an `include(...)` callback; calling one elsewhere throws.
 
 ```typescript
-await db.orm.User.include('posts', (posts) => posts.count()).all();
+await db.orm.public.User.include('posts', (posts) => posts.count()).all();
 // → Array<{ ...user, posts: number }> — a parent with no posts reads 0
 
-await db.orm.User.include('posts', (posts) => posts.sum('views')).all();
+await db.orm.public.User.include('posts', (posts) => posts.sum('views')).all();
 // → Array<{ ...user, posts: number | null }>
 
-await db.orm.User.include('posts', (posts) => posts.avg('views')).all();
+await db.orm.public.User.include('posts', (posts) => posts.avg('views')).all();
 // → Array<{ ...user, posts: number | null }>
 
-await db.orm.User.include('posts', (posts) => posts.min('views')).all();
-await db.orm.User.include('posts', (posts) => posts.max('views')).all();
+await db.orm.public.User.include('posts', (posts) => posts.min('views')).all();
+await db.orm.public.User.include('posts', (posts) => posts.max('views')).all();
 // → Array<{ ...user, posts: number | null }>
 
 // The lossless form, for a total that may outgrow a JS number:
-await db.orm.User.include('posts', (posts) => posts.sumBigInt('views')).all();
+await db.orm.public.User.include('posts', (posts) => posts.sumBigInt('views')).all();
 // → Array<{ ...user, posts: bigint | null }>
 
 // Several sub-views of one relation at once:
-await db.orm.User.include('posts', (posts) =>
+await db.orm.public.User.include('posts', (posts) =>
   posts.combine({ recent: posts.limit(3), total: posts.count() }),
 ).all();
 // → Array<{ ...user, posts: { recent: Post[]; total: number } }>
@@ -178,27 +178,27 @@ Nested `1:N → 1:N` includes (e.g. `User → posts → comments`) require the c
 
 ```typescript
 // Create — returns the inserted row.
-const user = await db.orm.User.create({ id, email, displayName, kind, createdAt });
+const user = await db.orm.public.User.create({ id, email, displayName, kind, createdAt });
 
 // Create with selected return — narrows the return shape.
-const summary = await db.orm.User
+const summary = await db.orm.public.User
   .select('id', 'email', 'kind')
   .create({ id, email, displayName, kind, createdAt });
 
 // Update by predicate.
-await db.orm.User.where({ id }).update({ email: newEmail });
+await db.orm.public.User.where({ id }).update({ email: newEmail });
 
 // Update with selected return.
-await db.orm.User
+await db.orm.public.User
   .where({ id })
   .select('id', 'email', 'kind')
   .update({ email: newEmail });
 
 // Delete by predicate.
-await db.orm.User.where({ id }).delete();
+await db.orm.public.User.where({ id }).delete();
 
 // Upsert — typed by the create branch's shape.
-await db.orm.User
+await db.orm.public.User
   .select('id', 'email', 'kind', 'createdAt')
   .upsert({
     create: { id, email, displayName, kind, createdAt: new Date() },
@@ -211,18 +211,18 @@ The ORM returns inserted / updated rows by default. The `.returning(...)` select
 ## Workflow — Aggregates
 
 ```typescript
-const totals = await db.orm.User.aggregate((aggregate) => ({
+const totals = await db.orm.public.User.aggregate((aggregate) => ({
   totalUsers: aggregate.count(),
 }));
 
-const adminTotals = await db.orm.User
+const adminTotals = await db.orm.public.User
   .where({ kind: 'admin' })
   .aggregate((aggregate) => ({
     adminUsers: aggregate.count(),
   }));
 
 // Group-by + aggregate.
-const byKind = await db.orm.User
+const byKind = await db.orm.public.User
   .groupBy('kind')
   .having((having) => having.count().gte(minUsers))
   .aggregate((aggregate) => ({
@@ -261,7 +261,7 @@ const byKind = await db.orm.User
 Nullability isn't a typing bug — it's faithful to what the database returns. Coalesce client-side when you want zero-fill:
 
 ```typescript
-const revenue = await db.orm.Sale
+const revenue = await db.orm.public.Sale
   .where((s) => s.day.gte(start))
   .aggregate((a) => ({ total: a.sum('amount') }));
 // revenue.total: number | null
@@ -271,22 +271,22 @@ const safe = revenue.total ?? 0;   // ← apply at the consumption site, not in
 
 If `?? 0` is showing up on every aggregate, that's a signal you're calling `sum` (or peers) over potentially-empty filters — which is exactly when SQL returns NULL. The pattern is correct; the typing is honest.
 
-## Workflow — SQL builder (`db.sql.<table>`)
+## Workflow — SQL builder (`db.sql.<ns>.<table>`)
 
-The concept: `db.sql.<table>` is a table-shaped builder that produces a *plan*. The plan is a serialisable description of the query (AST + parameters); you execute it through the runtime with `db.runtime().execute(plan)`. The builder gives you the lanes the ORM doesn't express — explicit `JOIN`, arbitrary expression projection, target-specific operations through extension helpers — without dropping to raw SQL.
+The concept: `db.sql.<ns>.<table>` is a table-shaped builder that produces a *plan*. The plan is a serialisable description of the query (AST + parameters); you run it through the runtime. Pick the runtime method by the result the plan declares: `db.runtime().query(plan)` for rows (it returns the same `AsyncIterableResult` as `.all()`, so `await` it for an array), `db.runtime().execute(plan)` for a write with no `RETURNING` (it resolves `{ affectedRows }` and returns no rows). The builder gives you the lanes the ORM doesn't express — explicit `JOIN`, arbitrary expression projection, target-specific operations through extension helpers — without dropping to raw SQL.
 
 ```typescript
 // src/queries/posts.ts — adjust the relative import to match file depth.
 import { db } from '../prisma/db';
 
 // Select with predicate and limit.
-const plan = db.sql.post
+const plan = db.sql.public.post
   .select('id', 'title', 'userId', 'createdAt')
   .where((f, fns) => fns.eq(f.userId, userId))
   .limit(limit)
   .build();
 
-const rows = await db.runtime().execute(plan);
+const rows = await db.runtime().query(plan);
 ```
 
 The `.where(...)` callback receives `(fields, fns)` — `fields` is the field proxy (column references), `fns` is the operator namespace (`fns.eq`, `fns.ne`, `fns.gt`, …). Extensions inject extension-shaped helpers into the same `fns` namespace (`fns.distanceSphere`, `fns.cosineDistance`, etc.).
@@ -294,27 +294,27 @@ The `.where(...)` callback receives `(fields, fns)` — `fields` is the field pr
 ### `INSERT` / `UPDATE` / `DELETE` with `RETURNING`
 
 ```typescript
-// Insert and return selected columns.
-const plan = db.sql.user
-  .insert({ email })
+// Insert and return selected columns. `insert()` takes an array of rows.
+const plan = db.sql.public.user
+  .insert([{ email }])
   .returning('id', 'email')
   .build();
-const [row] = await db.runtime().execute(plan);
+const [row] = await db.runtime().query(plan);
 
 // Update with predicate and returning.
-const updatePlan = db.sql.user
+const updatePlan = db.sql.public.user
   .update({ email: newEmail })
   .where((f, fns) => fns.eq(f.id, userId))
   .returning('id', 'email')
   .build();
-const rows = await db.runtime().execute(updatePlan);
+const rows = await db.runtime().query(updatePlan);
 
-// Delete with predicate.
-const deletePlan = db.sql.user
+// Delete with predicate, no RETURNING — `execute` resolves the affected count.
+const deletePlan = db.sql.public.user
   .delete()
   .where((f, fns) => fns.eq(f.id, userId))
   .build();
-await db.runtime().execute(deletePlan);
+const { affectedRows } = await db.runtime().execute(deletePlan);
 ```
 
 `.returning(...)` requires the target adapter to advertise the `returning` capability. The Postgres adapter advertises it by default.
@@ -323,36 +323,36 @@ await db.runtime().execute(deletePlan);
 
 ```typescript
 // Project a computed expression alongside model fields.
-const plan = db.sql.cafe
+const plan = db.sql.public.cafe
   .select('id', 'name')
   .select('meters', (f, fns) => fns.distanceSphere(f.location, point))
   .orderBy((f, fns) => fns.distanceSphere(f.location, point), { direction: 'asc' })
   .orderBy((f) => f.id, { direction: 'asc' })
   .limit(limit)
   .build();
-const rows = await db.runtime().execute(plan);
+const rows = await db.runtime().query(plan);
 
 // Self-join with an alias.
-db.sql.post
-  .innerJoin(db.sql.post.as('p2'), (f, fns) => fns.ne(f.p1.userId, f.p2.userId))
+db.sql.public.post
+  .innerJoin(db.sql.public.post.as('p2'), (f, fns) => fns.ne(f.p1.userId, f.p2.userId))
   // ...
   .build();
 ```
 
 ## Workflow — Transactions
 
-The concept: `db.transaction(fn)` opens a transaction and passes a `tx` context to the callback. `tx.orm` and `tx.sql` mirror `db.orm` / `db.sql` but ride the same transaction; `tx.execute(plan)` executes a SQL-builder plan within it. The transaction commits on the callback's successful return and rolls back on any thrown error.
+The concept: `db.transaction(fn)` opens a transaction and passes a `tx` context to the callback. `tx.orm` and `tx.sql` mirror `db.orm` / `db.sql` but ride the same transaction; `tx.query(plan)` / `tx.execute(plan)` run a SQL-builder plan within it (rows vs affected count, as on the runtime). The transaction commits on the callback's successful return and rolls back on any thrown error.
 
 ```typescript
 await db.transaction(async (tx) => {
-  const user = await tx.orm.User.create({ id, email });
-  await tx.orm.Post.create({ userId: user.id, title: 'hello' });
+  const user = await tx.orm.public.User.create({ id, email });
+  await tx.orm.public.Post.create({ userId: user.id, title: 'hello' });
 
-  // SQL-builder plan inside the transaction.
-  const plan = tx.sql.post.update({ status: 'archived' })
+  // SQL-builder plan inside the transaction — no RETURNING, so `execute`.
+  const plan = tx.sql.public.post.update({ status: 'archived' })
     .where((f, fns) => fns.lt(f.createdAt, cutoff))
     .build();
-  await tx.execute(plan);
+  const { affectedRows } = await tx.execute(plan);
 
   // If anything throws, all three operations roll back.
 });
@@ -362,20 +362,20 @@ The callback's return value passes through `db.transaction(...)`. Capture insert
 
 ## Namespace-aware accessors
 
-When the contract declares multiple namespaces, both `db.sql` and `db.orm` expose a namespace coordinate alongside the flat bare-name surface:
+On Postgres both `db.sql` and `db.orm` are keyed by storage namespace (the Postgres schema) — always, not only when a contract declares more than one. A model outside any `namespace { }` block is in `public`:
 
 ```typescript
 // db.sql.<namespace>.<table>
-const plan = db.sql.public.users.select('id', 'email').build();
+const plan = db.sql.public.user.select('id', 'email').build();
 const authPlan = db.sql.auth.users.select('id', 'token').build();
-await db.runtime().execute(plan);
+const rows = await db.runtime().query(plan);
 
 // db.orm.<namespace>.<Model>
 const user = await db.orm.public.User.create({ id: 1, email: 'a@x.io' });
 const authUser = await db.orm.auth.User.create({ id: 2, token: 'tok' });
 ```
 
-The flat `db.sql.users` / `db.orm.User` form still works when bare names are unique across all namespaces. When the same bare name appears in more than one namespace, use the coordinate form — both the type system and the runtime require it to resolve to the right table.
+There is no flat `db.sql.user` / `db.orm.User` on the Postgres façade (`Db` is "one facet per storage namespace, and nothing else"); reaching for one is a type error. The flat spelling belongs to SQLite, whose façade exposes its single unbound namespace directly — see `references/queries.md` § *Namespace-aware accessors*.
 
 Cross-namespace relations (e.g. `public.Profile` → `auth.User`) follow the same `.include()` syntax; the ORM resolves the correct schema-qualified join automatically.
 
@@ -385,13 +385,13 @@ Cross-namespace relations (e.g. `public.Profile` → `auth.User`) follow the sam
 2. **Using `.all()` when you wanted one row.** `.all()` issues no implicit limit. Use `.first()` or `.first({ pk })`.
 3. **Coalescing `count()` with `?? 0` "just in case".** `count()` is `number`, not `number | null` — SQL answers an empty set with `0`. The `?? 0` belongs on `sum` / `avg` / `min` / `max`, and its zero should match the aggregate's own type (`0` for an integer sum, `0n` for `sumBigInt`, `'0'` where the result is a decimal string).
 4. **Reaching for `.between(a, b)` on a field proxy.** It doesn't exist. Either chain `.where((m) => m.field.gte(a)).where((m) => m.field.lte(b))` or use `and(m.field.gte(a), m.field.lte(b))` inside one `.where()` clause.
-5. **Importing `and` / `or` / `not` from a Postgres façade subpath.** The combinators currently live in `@internal/sql-orm-client` — an internal package. See *What Prisma 8 doesn't do yet* in [`queries.md`](./queries.md).
-6. **Trying to `db.sql.from(tables.user)`.** That surface does not exist. The builder is table-shaped: `db.sql.<tableName>.select(...)`. There is no `db.schema.tables` either.
-7. **Trying to `db.execute(plan)` directly.** Plans execute through the runtime: `db.runtime().execute(plan)`. Inside a transaction, use `tx.execute(plan)`.
-8. **Setting `capabilities: { lateral: true }` in `prisma.config.ts`.** `defineConfig` does not take `capabilities`. Capabilities are declared by the active adapter and become part of the emitted contract; the Postgres adapter advertises `lateral`, `jsonAgg`, and `returning` out of the box. Enable extension capabilities through `extensions: [...]` in the config (see `references/contract.md`).
-9. **Confabulating a TypedSQL or `.stream()` surface.** Neither exists today. Raw SQL does: the client's raw lane, ``db.raw.sql`…` ``. See *What Prisma 8 doesn't do yet* in [`queries.md`](./queries.md) for all three.
-10. **Mixing the ORM mutation return with `runtime.execute(plan)`.** ORM terminals issue the query themselves and return rows. `runtime.execute` is for SQL-builder plans.
-11. **Ordering grouped rows by an aggregate metric.** The grouped collection supports `.orderBy(...)` on group keys plus `.limit(...)` / `.offset(...)`, but it cannot order by an aggregate alias such as `SUM(amount)`. Sorting the materialized aggregate result in JS is fine at small cardinalities; for large grouped result sets, drop to `db.sql.<table>`.
+5. **Importing `and` / `or` / `not` from an internal package.** They are exported from `@prisma/orm-postgres/orm-client`; do not reach into `@internal/sql-orm-client`.
+6. **Trying to `db.sql.from(tables.user)`.** That surface does not exist. The builder is table-shaped: `db.sql.<ns>.<tableName>.select(...)`. There is no `db.schema.tables` either.
+7. **Trying to `db.execute(plan)` directly, or reading rows with `execute`.** Plans run through the runtime: `db.runtime().query(plan)` for rows, `db.runtime().execute(plan)` for a non-returning write (`{ affectedRows }`). Inside a transaction, `tx.query(plan)` / `tx.execute(plan)`. `execute` never yields rows — a `select` or `.returning(...)` plan passed to it gives you statistics, not data.
+8. **Setting `capabilities: { lateral: true }` in `prisma.config.ts`.** The ORM config (`ormConfig({...})`) does not take `capabilities`. Capabilities are declared by the active adapter and become part of the emitted contract; the Postgres adapter advertises `lateral`, `jsonAgg`, and `returning` out of the box. Enable extension capabilities through `extensions: [...]` in the config (see `references/contract.md`).
+9. **Confabulating a TypedSQL or `.stream()` surface.** Neither exists. Raw SQL does: the client's raw lane, ``db.raw.sql`…` ``. Reusable statements do: `db.prepare(...)` (see *Prepared statements* in [`queries.md`](./queries.md)). Streaming: `for await` over a read terminal or `runtime.query(plan)` — with the caveats in *Streaming* in [`queries.md`](./queries.md).
+10. **Mixing the ORM mutation return with `runtime.query(plan)` / `runtime.execute(plan)`.** ORM terminals issue the query themselves and return rows. The runtime methods are for SQL-builder plans.
+11. **Ordering grouped rows by an aggregate metric.** The grouped collection supports `.orderBy(...)` on group keys plus `.limit(...)` / `.offset(...)`, but it cannot order by an aggregate alias such as `SUM(amount)`. Sorting the materialized aggregate result in JS is fine at small cardinalities; for large grouped result sets, drop to `db.sql.<ns>.<table>`.
 
 ## Reference Files
 
@@ -408,8 +408,8 @@ Cross-namespace relations (e.g. `public.Profile` → `auth.User`) follow the sam
 - [ ] Compared and serialised aggregate *results* as what they are — a `bigint` from a suffixed variant needs `0n` literals and `String(value)` rather than bare `JSON.stringify` — leaving the ORM's `having(...)` operands as numbers, and matching each SQL-builder comparison literal to the aggregate's own result codec (`fns.gt(fns.count(), 1)`).
 - [ ] Expressed ranges as chained `.where(...)` clauses or a single `and(...)` clause — did NOT reach for a non-existent `.between(...)` operator.
 - [ ] For cursor pagination, used `.orderBy(...).cursor({ field: lastValue }).limit(n).all()` — did NOT hand-write a `.where(p => p.field.lt(cursor))` workaround when the `.cursor()` API serves the same purpose.
-- [ ] For ORM combinators, imported `and` / `or` / `not` from the (currently internal) `@internal/sql-orm-client` and noted the façade gap to the user.
-- [ ] Executed SQL-builder plans via `db.runtime().execute(plan)` (or `tx.execute(plan)` inside a transaction).
+- [ ] For ORM combinators, imported `and` / `or` / `not` from `@prisma/orm-postgres/orm-client`.
+- [ ] Ran SQL-builder plans via `db.runtime().query(plan)` when they return rows and `db.runtime().execute(plan)` only for non-returning writes (`tx.query` / `tx.execute` inside a transaction). Passed `insert()` an array of rows.
 - [ ] Wrapped multi-statement work in `db.transaction(async (tx) => { ... })` where atomicity matters.
-- [ ] For top-N grouped aggregates at meaningful scale, dropped to `db.sql.<table>` rather than JS-side sort + slice over `groupBy(...).aggregate(...)`.
-- [ ] Did NOT confabulate TypedSQL, `.stream()`, `db.batch`, `.between(...)`, a `capabilities` field on `defineConfig`, or a `db.sql.from(tables.user)` API — routed to *What Prisma 8 doesn't do yet* / `references/feedback.md` instead. Raw SQL is spelled `db.raw.sql`, not `db.sql.raw`.
+- [ ] For top-N grouped aggregates at meaningful scale, dropped to `db.sql.<ns>.<table>` rather than JS-side sort + slice over `groupBy(...).aggregate(...)`.
+- [ ] Did NOT confabulate TypedSQL, `.stream()`, `db.batch`, `.between(...)`, a collection-level `.count()`, a `capabilities` field on the config, or a `db.sql.from(tables.user)` API — routed to *What Prisma 8 doesn't do yet* / `references/feedback.md` instead. Raw SQL is spelled `db.raw.sql`, not `db.sql.raw`.