Preview feature feedback: @prisma/adapter-pg / PostgreSQL Driver support

[nikolasburk]

Support for the node-postgres driver (pg) is in preview behind the driverAdapters preview feature.

Please share your feedback about @prisma/adapter-pg in this discussion.

• If you encounter a bug, please open a bug report in this repo.
• If the feature is working well for you, please share this in a comment below or leave a 👍 on this issue.
• If you have any questions, don't hesitate to ask them in the Prisma Discord community

[theguacamoleking]

Hey @nikolasburk!

The feature looks great but it seems that Prisma prepends all select statements with the public schema.

SELECT "public".* FROM "TABLE"

Is there a way to get prisma to not include the schema in the resulting query — that way the user can configure the default schema on the pool?

Alternatively, is there a way to inform Prisma of the schema?

[nikolasburk]

Ha, good question! Did you try configuring the schema on your connection string as documented here? For example, assume your schema is called myschema:

postgresql://user:password@host:port/db?schema=myschema

Can you confirm that you did this and Prisma Client still prepends statements with the public schema name? If so, that's probably a bug that we should fix!

[SevInf]

Hi @theguacamoleking!
Configuring schema is done slightly differently when you are using adapter. If you want to use custom schema as default, use following code to instantiate your adapter:

const adapter = new PrismaPg(pool, {
  schema: 'myDbSchema'
})

This is something the slipped into release without documentation, I've created an issue to fix this.

[alonbilu]

Hi
Not sure that's the right place to ask, but.. :)
Anyways, I read the docs but couldn't find an answer for why would one consider switching to Node.js's native driver over using the one built in with Prisma...minding I'm connecting to PostgreSQL server, are there any benefits of doing this transition?
Thanks for clarifying this.

[janpio]

Good question!

In certain environments, the built-in drivers are not available - for example on Cloudflare Workers or Vercel Edge Functions because they run a non-Node runtime that does not support the kind of functionality required (TCP socket support). For some of these cases, you can use @prisma/adapter-pg instead where support - Cloudflare makes that possible with their connect() TCP feature which was implemented by pg - so you can talk to your normal PostgreSQL database from Cloudflare Workers using pg via @prisma/adapter-pg.

Another angle might be that you just prefer the APIs of pg for configuration or connection pooling. With @prisma/adapter-pg you can do that if you want.

(If you have no pain point that makes you move away from the built-in drivers, then you probably don't need to.)

[srujun]

Is it expected that using @prisma/adapter-pg speeds up Prisma operations significantly as compared to using the native Prisma driver? I am running a test in which I am sending around 40 queries concurrently, and repeating this a few times. I am noticing that the first few queries are much slower when using the Prisma driver and take around 200ms-300ms to complete, and then subsequent queries are able to finish within 10ms-20ms. When using @prisma/adapter-pg, the first few queries all finish within 20ms-50ms, and subsequent queries are able to finish within the same 10ms-20ms duration. In both cases I am using a connection pool of size 20 (using connection_limit=20 in the connection string when using the native Prisma driver, and setting max: 20 in pg.Pool when using @prisma/adapter-pg).

Why is the native Prisma driver slower?

[janpio]

That can have all kinds of reasons, srujun. The native driver for example has a more secure default configuration than pg, which with some database configurations makes opening connections slower. If you can reproduce this, please open an issue with reproduction steps and we can take a look.

[peterHakio]

I guess it is linked to #23573