[Performance] How to trace Prisma down to the SQL query level?

[danthareja]

Context

I'd like to use Sentry to measure the performance impact of Prisma's decision to not use native JOINS for relational databases. Here's what they currently do:

Prisma Client:

const usersWithPosts = await prisma.user.findMany({
  include: {
    posts: true,
  },
})

Resulting SQL:

SELECT "public"."User"."id", "public"."User"."email", "public"."User"."name" FROM "public"."User" WHERE 1=1 OFFSET $1
SELECT "public"."Post"."id", "public"."Post"."title", "public"."Post"."authorId" FROM "public"."Post" WHERE "public"."Post"."authorId" IN ($1,$2,$3,$4) OFFSET $5

Description

Today, Sentry.Integrations.Prisma groups the timing of the SQL calls into a single db.sql.prisma transaction

I'd love to be able to see each SQL call in it's own span.

Resources

Prisma provides it's own Open Telementry tracing which exposes these details.

Is it possible to hook this into Sentry?

[AbhiPrasad]

Hey, thanks for writing in! I explored this a little with #5780, and Prisma is a bit of a black box, so OTEL is the way to go here.

We have some docs about OpenTelemetry instrumentation with Sentry performance, but we're also working on improving this workflow as part of #8534.

[danthareja]

Thanks so much for the response @AbhiPrasad.

This might be a silly question, but is the OTEL instrumenter mutually exclusive with Sentry?

[AbhiPrasad]

Not a silly question at all - at the current moment they are mutually exclusive. This happens because we want to avoid double instrumenting (sentry perf creating the same span that an otel sdk does) which is confusing and causes unnecessary overhead.

We are re-evaluating this with the work in #8534, so might change soon!

[danthareja]

I'll keep an eye on that issue, thanks!!