Add instrumentation for postgres package

Problem Statement

As a developer I would like postgresjs queries to be instrumented.

Solution Brainstorm

As discussed on discord...

https://github.com/porsager/postgres is a popular postgres client library
I would be great if it also would be supported for auto instrumentation

Side note: For a sveltekit project it's not super easy to use instrumentation via --import as everything gets bundled by default.

Hi, thanks for writing in!

It appears as if there's no official Otel instrumentation for postgres. A quick Google search reveals this one but it's rather old by now: https://github.com/tomsanbear/opentelemetry-instrumentation-postgres

We can look into creating one. I'll backlog this for now.

Side note: For a sveltekit project it's not super easy to use instrumentation via --import as everything gets bundled by default.

Yup that's a good point and most definitely on our radar (but priorities, time, the usual).

More specifically, there are two problems:

initing the SDK early enough for most Otel instrumentation to work is a pain because --import can't be set on all deployment providers (e.g. Netlify). I have a rough idea how SvelteKit can be a better citizen here but this most definitely requires framework changes.
SvelteKit bundling all its deps by default completely kills the chance of getting instrumentation as OpenTelemetry "listens" for import statements.

Regarding 2, You can try to mark postgres as an external dependency so that vite doesn't bundle it. I haven't tried this myself though so I'd also be curious if this solves it.

I have a rough idea how SvelteKit can be a better citizen here but this most definitely requires framework changes.

As in SvelteKit changes?

You can try to mark postgres as an external dependency so that vite doesn't bundle it. I haven't tried this myself though so I'd also be curious if this solves it.

For now I switched to manual instrumentations - but those span don't show up either :-(

Should I open a support case for that?

It seems like this is the right place to init

https://svelte.dev/docs/kit/hooks#Shared-hooks-init

import * as db from '$lib/server/database';
import type { ServerInit } from '@sveltejs/kit';

export const init: ServerInit = async () => {
    await db.connect();
};

...not sure if that's enough

As in SvelteKit changes?

yes. NextJS exposes a framework-native way where users can init the SDK in a special instrumentation.ts file. The framework then takes care of ensuring that this file is built and evaluated before the rest of the server code is imported. I believe SvelteKit (or any meta framework for that matter) needs to expose a similar mechanism. Otherwise, users are stuck with figuring a way out to --import the file)

It seems like this is the right place to init

Unfortunately, the SvelteKit init hook is not the right place. This happens too late.

In a nutshell, there are two ways how you can ensure that you init early enough in ESM-based frameworks:

Use --import instrument.ts (which is really tricky with meta frameworks and cloud providers abstracting infra stuff away from users)
So something like this:

// index.js
import * as Sentry from '@sentry/sveltekit'
Sentry.init({...});
// or any OpenTelemetry SDK for that matter

await import('./actualServerEntryPoint')

Since await import is evaluated at runtime, the SDK could already register the ESM loader hook beforehand, meaning all subsequent import statements in the server code go through OpenTelemetry's instrumentation and get instrumented correctly.

For now I switched to manual instrumentations - but those span don't show up either :-(
Should I open a support case for that?

This shouldn't happen. Can you open a separate issue in this repo? Please fill out the issue template so that we know how you set up and configure the SDK. Thanks! I wanna avoid conflating this one more as the main request here is to add instrumentation for postgres (which is independent of any SvelteKit-specific issue).

Why was this issue closed?

This issue hasn't been touched recently and no longer seems relevant.
Hence, we're closing it to maintain a clean and transparent backlog.

Please feel free to leave a comment if you think this issue should be reopened.

I am confused by the "Why was this closed".
Did it get implemented or not?

Sorry, you are right, this got a bit confusing because a few different things came together in this issue. The postgres part is def. still open and something we eventually want to do!

feat(node): Add postgresjs instrumentation (#16665)

A PR closing this issue has just been released 🚀

This issue was referenced by PR #16665, which was included in the 9.33.0 release.

Navigation Menu

Repository navigation

Add instrumentation for `postgres` package #15621

Problem Statement

Solution Brainstorm

17 remaining items

A PR closing this issue has just been released 🚀

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add instrumentation for postgres package #15621

Description

Problem Statement

Solution Brainstorm

Activity

Lms24 commented on Mar 10, 2025

tcurdt commented on Mar 10, 2025

tcurdt commented on Mar 10, 2025

Lms24 commented on Mar 10, 2025

Lms24 commented on Mar 10, 2025

17 remaining items

mydea commented on Apr 10, 2025

tcurdt commented on Apr 10, 2025

mydea commented on Apr 11, 2025

github-actions commented on Jun 27, 2025

A PR closing this issue has just been released 🚀

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Add instrumentation for `postgres` package #15621