Bug description

Prisma 7.4.0 introduced a regression in cursor-based pagination when using driver adapters (like @prisma/adapter-mariadb).

7.3.0 generates: ...ORDER BY created_at DESC LIMIT ? OFFSET ? — MySQL handles pagination natively

7.4.0 generates: ...AND created_at <= (SELECT created_at FROM projects WHERE public_id = ?) ORDER BY created_at DESC — uses a subquery for cursor positioning with no LIMIT/OFFSET in SQL;

I won't get into the merit of id based pagination vs limit offset, the benefits are well known and documented, but I will say that this change does break existing behaviour.

Severity

🚨 Critical: Data loss, app crash, security issue

Reproduction

https://github.com/aaronjwhiteside-appdirect/prisma-cursor-repro

Instructions in the repos README.md

Expected vs. Actual Behavior

// Page 1 — works fine
const page1 = await prisma.post.findMany({
  orderBy: { createdAt: "desc" },
  take: 2,
  skip: 0,
});

const cursor = page1[0].publicId;

// Page 2 — returns [] in 7.4.0, should return 1 result
const page2 = await prisma.post.findMany({
  orderBy: { createdAt: "desc" },
  take: 2,
  skip: 1,
  cursor: { publicId: cursor },
});

Frequency

Consistently reproducible

Does this occur in development or production?

Both development and production

Is this a regression?

Worked in 7.3

Workaround

Downgrade fixes it.

Prisma Schema & Queries

// Add relevant schema.prisma snippet

// Add relevant Prisma Client query

See referenced repo that reproduces the issue

Prisma Config

// Add your `prisma.config.ts`

See referenced repo that reproduces the issue

Logs & Debug Info

// Debug logs here

Environment & Setup

• OS:
  macOS
• Database:
  MySQL
• Node.js version:
  v22.22.0

Prisma Version

// Prisma version output
v7.4