Prisma Next — Queries

Edit your data contract. Prisma handles the rest.

Once the contract is emitted and the DB is up to date, this skill covers everything you do with the data: reading, writing, eager-loading relations, aggregating, and the choice between the ORM and the SQL builder.

When to Use

User wants to read, write, update, or delete data.
User wants to include / eager-load relations.
User wants to paginate, sort, filter, project.
User wants to wrap operations in a transaction (
```
db.transaction(...)
```
).
User wants to aggregate (
```
count
```
,
```
sum
```
,
```
avg
```
, …).
User asks about query lanes (ORM vs SQL builder).
User mentions: query, select, where, orderBy, take, skip, include, eager load, first, all, count, aggregate, create, update, delete, upsert, returning, drizzle-style, kysely-style, prisma client.

When Not to Use

User wants to add / change a model →
```
prisma-next-contract
```
.
User wants to wire
```
db.ts
```
or add middleware →
```
prisma-next-runtime
```
.
User wants to debug a query failure (structured error envelope) →
```
prisma-next-debug
```
.

Key Concepts

Prisma Next ships two query lanes on top of one contract today, both reached through the same

db

value from

src/prisma/db.ts

(which the

@prisma-next/<target>/runtime

façade returns):

db.orm.<Model>
— the ORM. Model-shaped (
```
db.orm.User
```
), fluent (
```
.where(...).select(...).orderBy(...).all()
```
), fully typed against
```
Contract
```
. Default lane for CRUD with relations.
db.sql.<table>
— the SQL builder. Table-shaped (
```
db.sql.user
```
, lowercase by storage name), produces a plan you execute through the runtime. Use when the ORM is too high-level — explicit
```
JOIN
```
, computed projections that aren't model fields, set operations, window functions.

The two lanes share the same contract, the same connection, and the same transaction context — they compose cleanly. Reach for the ORM first; drop to

db.sql

when the ORM is too high-level. The lane choice is local: a single query function picks one lane, not the whole app.

Lane decision table:

Need	Choose	Why
Standard CRUD with relations	ORM ( `db.orm.<Model>` )	Highest ergonomics; fully typed; model-shaped.
Eager-load related records	ORM `.include(...)`	Composes with `.where` / `.select` / `.orderBy` / `.take` 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.
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` ).

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)

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 });
// Returns the full row or `null`.

// Find one matching a predicate.
const alice = await db.orm.User
  .where((u) => u.email.eq('alice@example.com'))
  .first();

// Find many with projection, sort, and limit.
const recentUsers = await db.orm.User
  .select('id', 'email', 'createdAt')
  .orderBy((u) => u.createdAt.desc())
  .take(10)
  .all();

Predicates (

.where(...)

) come in two forms:

typescript

// Lambda form — full expression power.
db.orm.User.where((u) => u.email.eq('alice@example.com'));

// Shorthand object form — equality on the named fields.
db.orm.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

.cosineDistance(...)

postgis

.within(...)

.intersectsBbox(...)

.distanceSphere(...)

cipherstash

.cipherstashEq(...)

.cipherstashGt(...)

/ …).

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
  .where((s) => s.day.gte(start))
  .where((s) => s.day.lte(end))
  .all();

// Equivalent with an explicit `and(...)` inside one clause.
import { and } from '@prisma-next/sql-orm-client'; // façade re-export pending — see *What PN doesn't do yet*
await db.orm.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

@prisma-next/sql-orm-client

package — see What Prisma Next doesn't do yet for the façade-completeness gap:

typescript

import { and, or, not } from '@prisma-next/sql-orm-client';

await db.orm.User
  .where((u) =>
    and(
      or(u.kind.eq('admin'), u.email.ilike('%@example.com')),
      not(u.posts.none((p) => p.title.ilike('%draft%'))),
    ),
  )
  .all();

Sorting and pagination.

.orderBy(...)

accepts a single lambda or an array of lambdas (each calling

.asc()

.desc()

on a field).

.take(n)

limits;

.skip(n)

offsets.

typescript

await db.orm.Post
  .where((p) => p.authorId.eq(userId))
  .orderBy([(p) => p.createdAt.desc(), (p) => p.id.desc()])
  .take(20)
  .all();

// Cursor pagination — order by an indexed unique column and filter past the cursor.
const cursor = lastPostFromPreviousPage.createdAt;
await db.orm.Post
  .where((p) => p.createdAt.lt(cursor))
  .orderBy((p) => p.createdAt.desc())
  .take(20)
  .all();

.first()
vs
.first({ pk })
vs
.all()
. Use

.first()

for a single row (issues a

LIMIT 1

); use

.first({ pk })

for primary-key lookups; reserve

.all()

for the genuine many case (no implicit

LIMIT

Consuming the result:

await

.toArray()

, or

for await

Critical to get right early —

.all()

returns an AsyncIterableResult<Row>
, which is both a

PromiseLike<Row[]>

and an

AsyncIterable<Row>

. That means three consumption forms all work, and the canonical one is the shortest:

typescript

const users = await db.orm.User.select('id', 'email').all();
//    ^? Row[]   ← the Thenable resolves to a real array. This is the default idiom.

You do not need a

collect()

toArray()

helper —

await

is enough. Internally

await

invokes the result's

then(...)

, which buffers the rows into an array. Two equivalent alternatives exist for the cases where they read better:

typescript

// Explicit buffering — same outcome as `await ... .all()`, useful when you
// want a named Promise<Row[]> to thread through downstream code.
const rows: Promise<User[]> = db.orm.User.select('id', 'email').all().toArray();

// Streaming — process rows one at a time without buffering the whole result.
// Use for genuinely large result sets (anything that wouldn't fit comfortably
// in memory) or pipelines where you can start work before all rows arrive.
for await (const user of db.orm.User.select('id', 'email').all()) {
  process(user);
}

Two single-row shortcuts also exist on the result, in addition to the collection-level

.first()

(which issues

LIMIT 1

typescript

const user = await db.orm.User.where({ id }).all().first();
//    ^? Row | null   ← buffers, returns the first row or null. Issues no LIMIT.
const required = await db.orm.User.where({ id }).all().firstOrThrow();
//    ^? Row          ← buffers; throws `RUNTIME.NO_ROWS` if empty.

For genuine single-row reads, prefer the collection-level

.first()

(which adds

LIMIT 1

to the SQL) over

.all().first()

(which fetches all rows and discards the rest). The result-level helpers are for cases where you already need the full result and want the first row without an extra round-trip.

The result is single-consumption. Each

AsyncIterableResult

instance can be consumed once — by

await

, by

.toArray()

, or by

for await

. Trying to consume it a second time throws RUNTIME.ITERATOR_CONSUMED
. The fix is almost always to store the array in a variable on first consumption and reuse the variable:

typescript

// Bad — second await throws RUNTIME.ITERATOR_CONSUMED.
const result = db.orm.User.select('id', 'email').all();
const a = await result;
const b = await result;

// Good — buffer once, reuse the array.
const users = await db.orm.User.select('id', 'email').all();
const a = users;
const b = users;

If you've seen

collect(...)

toArray(...)

helpers in a codebase wrapping

.all()

, they're vestigial —

await

does the same thing for free. Remove them when you touch the surrounding code.

Workflow — Eager-loading relations (

.include

)

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

.take

on it just like the parent.

typescript

await db.orm.User
  .select('id', 'email')
  .include('posts', (post) =>
    post
      .select('id', 'title', 'createdAt')
      .orderBy((p) => p.createdAt.desc())
      .take(5),
  )
  .take(10)
  .all();
// → Array<{ id, email, posts: Array<{ id, title, createdAt }> }>

Nested

1:N → 1:N

includes (e.g.

User → posts → comments

) require the contract to advertise the

lateral

jsonAgg

capabilities for the active target. The Postgres adapter advertises both by default, so most apps get this for free; if the type system rejects a nested include with a missing capability error, route to

prisma-next-contract

to add the required capability declarations and use

prisma-next-queries

for query-shape guidance.

Workflow — ORM writes

typescript

// Create — returns the inserted row.
const user = await db.orm.User.create({ id, email, displayName, kind, createdAt });

// Create with selected return — narrows the return shape.
const summary = await db.orm.User
  .select('id', 'email', 'kind')
  .create({ id, email, displayName, kind, createdAt });

// Update by predicate.
await db.orm.User.where({ id }).update({ email: newEmail });

// Update with selected return.
await db.orm.User
  .where({ id })
  .select('id', 'email', 'kind')
  .update({ email: newEmail });

// Delete by predicate.
await db.orm.User.where({ id }).delete();

// Upsert — typed by the create branch's shape.
await db.orm.User
  .select('id', 'email', 'kind', 'createdAt')
  .upsert({
    create: { id, email, displayName, kind, createdAt: new Date() },
    update: { email, displayName, kind },
  });

The ORM returns inserted / updated rows by default. The

.returning(...)

selector lives on the SQL builder (next section), where you build a plan and execute it explicitly.

Workflow — Aggregates

typescript

const totals = await db.orm.User.aggregate((aggregate) => ({
  totalUsers: aggregate.count(),
}));

const adminTotals = await db.orm.User
  .where({ kind: 'admin' })
  .aggregate((aggregate) => ({
    adminUsers: aggregate.count(),
  }));

// Group-by + aggregate.
const byKind = await db.orm.User
  .groupBy('kind')
  .having((having) => having.count().gte(minUsers))
  .aggregate((aggregate) => ({
    totalUsers: aggregate.count(),
  }));

aggregate

exposes

.count()

.sum(field)

.avg(field)

.min(field)

.max(field)

. Project the aggregates into named result keys; the result type narrows accordingly.

Aggregate nullability matches SQL semantics:

Aggregate	Type	Empty result
`count()`	`number`	`0`
`sum(field)`	`number \| null`	`null` (SQL `SUM` over zero rows is `NULL` )
`avg(field)`	`number \| null`	`null`
`min(field)`	`number \| null`	`null`
`max(field)`	`number \| null`	`null`

This 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
  .where((s) => s.day.gte(start))
  .aggregate((a) => ({ total: a.sum('amount') }));
// revenue.total: number | null

const safe = revenue.total ?? 0;   // ← apply at the consumption site, not in the aggregate spec.

?? 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>

)

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.

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
  .select('id', 'title', 'userId', 'createdAt')
  .where((f, fns) => fns.eq(f.userId, userId))
  .limit(limit)
  .build();

const rows = await db.runtime().execute(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.).

INSERT

UPDATE

DELETE

with

RETURNING

typescript

// Insert and return selected columns.
const plan = db.sql.user
  .insert({ email })
  .returning('id', 'email')
  .build();
const [row] = await db.runtime().execute(plan);

// Update with predicate and returning.
const updatePlan = db.sql.user
  .update({ email: newEmail })
  .where((f, fns) => fns.eq(f.id, userId))
  .returning('id', 'email')
  .build();
const rows = await db.runtime().execute(updatePlan);

// Delete with predicate.
const deletePlan = db.sql.user
  .delete()
  .where((f, fns) => fns.eq(f.id, userId))
  .build();
await db.runtime().execute(deletePlan);

.returning(...)

requires the target adapter to advertise the

returning

capability. The Postgres adapter advertises it by default.

Computed projections and joins

typescript

// Project a computed expression alongside model fields.
const plan = db.sql.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);

// Self-join with an alias.
db.sql.post
  .innerJoin(db.sql.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.

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' });

  // SQL-builder plan inside the transaction.
  const plan = tx.sql.post.update({ status: 'archived' })
    .where((f, fns) => fns.lt(f.createdAt, cutoff))
    .build();
  await tx.execute(plan);

  // If anything throws, all three operations roll back.
});

The callback's return value passes through

db.transaction(...)

. Capture inserted ids out of the callback and use them downstream after commit.

Running queries from a short script

When the user is running a one-off

tsx my-script.ts

(not a long-lived server), call

await db.close()

at the end so the process exits cleanly — especially on Postgres, where the façade-owned pool otherwise keeps Node's event loop alive. See

prisma-next-runtime

§ Running as a script (teardown) for the full pattern including

await using

typescript

// src/scripts/seed.ts
import { db } from '../prisma/db';

for (const u of users) {
  await db.orm.User.create(u);
}
console.log('Seeded.');

await db.close();

Common Pitfalls

Reaching for
db.sql
when
db.orm
would have done. The ORM covers most CRUD shapes; the SQL builder is the seam for the shapes it doesn't. Default to the ORM.
Using
.all()
when you wanted one row.
```
.all()
```
issues no implicit
```
LIMIT
```
. Use
```
.first()
```
(issues
```
LIMIT 1
```
) or
```
.first({ pk })
```
.
Writing a
collect()
/
toArray()
helper to convert
.all()
to an array.
```
.all()
```
returns an
```
AsyncIterableResult<Row>
```
which is a
```
PromiseLike<Row[]>
```
—
```
await collection.all()
```
directly yields
```
Row[]
```
. The helpers some codebases ship are vestigial. See Consuming the result.
Consuming an
AsyncIterableResult
twice. Each result is single-use. The second consumer throws
```
RUNTIME.ITERATOR_CONSUMED
```
. Buffer once into a variable and reuse the variable.
Coalescing
count()
with
?? 0
"just in case".
```
count()
```
is
```
number
```
, not
```
number | null
```
— the runtime already substitutes
```
0
```
for the empty case. The
```
?? 0
```
belongs on
```
sum
```
/
```
avg
```
/
```
min
```
/
```
max
```
, whose
```
number | null
```
shape is faithful to SQL semantics over empty result sets.

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.

Importing
and
/
or
/
not
from a façade subpath. The combinators currently live in
```
@prisma-next/sql-orm-client
```
— an internal package. See What Prisma Next doesn't do yet.
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.
Trying to
db.execute(plan)
directly. Plans execute through the runtime:
```
db.runtime().execute(plan)
```
. Inside a transaction, use
```
tx.execute(plan)
```
.
Setting
capabilities: { includeMany: true }
in
prisma-next.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
```
prisma-next-contract
```
).
Confabulating a
db.sql.raw(...)
, TypedSQL, or
.stream()
surface. None of those exist today. See What Prisma Next doesn't do yet.
Mixing the ORM mutation return with
db.execute(plan)
. The ORM's terminal verbs (
```
.create
```
,
```
.update
```
,
```
.delete
```
,
```
.first
```
,
```
.all
```
,
```
.aggregate
```
) issue the query themselves and return rows. Don't pass the builder to
```
db.runtime().execute(...)
```
— that's for SQL-builder plans.
Top-N grouped queries written as
groupBy(...).aggregate(...).sort().slice()
in JS. That's a fallback because the grouped collection doesn't expose
```
.orderBy(...)
```
/
```
.take(...)
```
(see What PN doesn't do yet). Fine at small cardinalities; for genuinely large grouped result sets, drop to
```
db.sql.<table>
```
and write
```
GROUP BY
```
+
```
ORDER BY
```
+
```
LIMIT
```
against the table directly.

What Prisma Next doesn't do yet

and
/
or
/
not
combinators in the postgres façade. The combinators currently import from
```
@prisma-next/sql-orm-client
```
(an internal package). Tracked alongside other façade-completeness gaps in Linear
```
TML-2526
```
. Workaround today: import them from
```
@prisma-next/sql-orm-client
```
directly, the way the example apps do. If you want them on
```
@prisma-next/postgres/runtime
```
, file a feature request via
```
prisma-next-feedback
```
.
.orderBy(...)
/
.take(...)
on grouped aggregates.
```
db.orm.<Model>.groupBy(...).aggregate(...)
```
materializes a
```
Promise<Array<Group & Aggregates>>
```
and exposes neither ordering nor row limits at the DB layer. Result: a "top-N groups by SUM" query falls back to JS-side sort + slice over the full grouped result, which is fine at small cardinalities and bad at scale. Workarounds: (a) drop to
```
db.sql.<table>
```
and write the
```
GROUP BY
```
+
```
ORDER BY
```
+
```
LIMIT
```
against the aggregated table directly; (b) live with the JS-side sort/slice if the grouped cardinality is bounded. File a feature request via
```
prisma-next-feedback
```
if this is hitting you in production.
A raw-SQL lane. Prisma Next does not currently expose a user-facing raw-SQL surface (no
```
db.sql.raw(...)
```
). Workaround: model the query through the SQL builder or — for shapes the builder can't yet express — file a feature request via
```
prisma-next-feedback
```
describing the shape so the team can decide whether to grow the builder or ship a raw lane.
TypedSQL (
.sql
files compiled into typed callables). Not implemented. Workaround: stick to the SQL builder; for repeated queries, extract a function that returns the built plan and call
```
db.runtime().execute(plan)
```
at the call site. If you want a
```
.sql
```
-file compile path, file a feature request via
```
prisma-next-feedback
```
.
EXPLAIN
/ query-plan inspection. Prisma Next does not expose an
```
.explain()
```
method. Workaround: connect a
```
pg.Pool
```
you control via the runtime's
```
pg:
```
binding (see
```
prisma-next-runtime
```
) and issue
```
EXPLAIN ANALYZE
```
through it. If you want a first-class plan-inspection surface, file a feature request via
```
prisma-next-feedback
```
.
Streaming large result sets. No
```
.stream()
```
cursor today. Workaround: paginate via
```
.skip(n).take(m)
```
for moderate sizes; for very large sets, hold a
```
pg.Client
```
from the runtime's
```
pg:
```
binding and stream through it directly. If you want a built-in streaming surface, file a feature request via
```
prisma-next-feedback
```
.
Multi-statement batching (Prisma-7-style
db.$transaction([call1, call2])
). Prisma Next runs each call sequentially. Workaround: wrap atomically-related work in
```
db.transaction(async (tx) => { ... })
```
. If you want batch-as-array semantics, file a feature request via
```
prisma-next-feedback
```
.
Automatic N+1 detection. Prisma Next does not warn when an
```
.include(...)
```
is missing. Workaround: be deliberate about
```
.include(...)
```
in code review; the
```
lints
```
middleware (see
```
prisma-next-runtime
```
) catches the more common authoring slips (missing
```
WHERE
```
on a
```
DELETE
```
/
```
UPDATE
```
, missing
```
LIMIT
```
on a
```
SELECT
```
).

Reference Files

This skill is intentionally body-only. The authoritative surfaces are:

The example queries under
```
examples/prisma-next-demo/src/orm-client/
```
and
```
examples/prisma-next-demo/src/queries/
```
— the canonical worked references for ORM and SQL-builder shapes respectively.
The ORM client source under
```
packages/3-extensions/sql-orm-client/src/
```
for the full collection method surface.
The SQL builder source under
```
packages/2-sql/4-lanes/sql-builder/src/
```
for the builder method surface.

Checklist

Chose the right lane (ORM by default; SQL builder for set-builder shapes the ORM doesn't express).
Used
```
.first()
```
/
```
.first({ pk })
```
for single-row reads — not
```
.all()
```
.
Consumed
```
.all()
```
with plain
```
await
```
(not a
```
collect()
```
/
```
toArray()
```
helper). Used
```
for await
```
only when streaming is actually wanted, and never iterated the same result twice.
Coalesced
```
sum
```
/
```
avg
```
/
```
min
```
/
```
max
```
results with
```
?? 0
```
(or similar) at the consumption site when zero-fill is desired — did NOT coalesce
```
count()
```
, which is
```
number
```
.
Expressed ranges as chained
```
.where(...)
```
clauses or a single
```
and(...)
```
clause — did NOT reach for a non-existent
```
.between(...)
```
operator.
For ORM combinators, imported
```
and
```
/
```
or
```
/
```
not
```
from the (currently internal)
```
@prisma-next/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).
Wrapped multi-statement work in
```
db.transaction(async (tx) => { ... })
```
where atomicity matters.

Did NOT confabulate

db.sql.raw

, TypedSQL,

.stream()

db.batch

.between(...)

, a

capabilities

field on

defineConfig

, or a

db.sql.from(tables.user)

API — routed to What Prisma Next doesn't do yet /

prisma-next-feedback

instead.

For top-N grouped aggregates at meaningful scale, dropped to
```
db.sql.<table>
```
rather than JS-side sort + slice over
```
groupBy(...).aggregate(...)
```
.
Did NOT use the SQL builder for something the ORM cleanly expresses.

prisma-next-queries

NPX Install

Tags

SKILL.md Content

Prisma Next — Queries

When to Use

When Not to Use

Key Concepts

Workflow — ORM reads

Consuming the result:
`await`
,
`.toArray()`
, or
`for await`

Workflow — Eager-loading relations (
`.include`
)

Workflow — ORM writes

Workflow — Aggregates

Workflow — SQL builder (
`db.sql.<table>`
)

`INSERT`
/
`UPDATE`
/
`DELETE`
with
`RETURNING`

Computed projections and joins

Workflow — Transactions

Running queries from a short script

Common Pitfalls

What Prisma Next doesn't do yet

Reference Files

Checklist

prisma-next-queries

NPX Install

Tags

SKILL.md Content

Prisma Next — Queries

When to Use

When Not to Use

Key Concepts

Workflow — ORM reads

Consuming the result: await, .toArray(), or for await

Workflow — Eager-loading relations (.include)

Workflow — ORM writes

Workflow — Aggregates

Workflow — SQL builder (db.sql.<table>)

INSERT / UPDATE / DELETE with RETURNING

Computed projections and joins

Workflow — Transactions

Running queries from a short script

Common Pitfalls

What Prisma Next doesn't do yet

Reference Files

Checklist

Consuming the result:
`await`
,
`.toArray()`
, or
`for await`

Workflow — Eager-loading relations (
`.include`
)

Workflow — SQL builder (
`db.sql.<table>`
)

`INSERT`
/
`UPDATE`
/
`DELETE`
with
`RETURNING`